Johan Sundström wrote:
> On 2/5/07, David Huynh <[EMAIL PROTECTED]> wrote:
>
>> Johan Sundström wrote:
>>
>>> Is there any reason why the id property of items are not available as
>>> facets, ex:content data and the like? I'd like to list my cities in
>>> the facet browse panel as .location.city.id, but can't (the facet does
>>> not show up at all).
>>>
>>> http://ecmanaut.googlepages.com/choir-events.html
>>>
>> Can you use .label instead? Not the same but almost. For that particular
>> example, I think .location.city would be sufficient.
>>
>> I just thought "id" isn't really a property. But I'm open to more
>> flexibility.
>>
>
> I do, at the moment, though I'd prefer the flexibility. I organized my
> city id:s so they would be fully qualified by country and city name
> and thus unique enough for the scope of this hack, and used labels to
> convey the name of a city alone. In my facet view I would want to show
> the fully qualified name, though, so people could tell Paris, France
> from Paris, Tennessee, For instance.
>
actually, i would be inclined to do this by adding a new,
"fullyQualifiedAddress" property. That will make it easier to integrate
your exhibit with someone else's that might not use the same approach as
you do for choosing ids.
> Of course I'd gladly do that with a facet specification along the
> lines of ".location.city + ', ' + .location.city.country", but I had a
> feeling that might be asking a bit much again. ;-) I'm also one for
> flexibility, though, and so far I have not dug deep enough in the
> language / expression bits of the code to understand what is so
> difficult about supporting that kind of flexibility. (Users believe
> this liberates them from being limited by whatever obstacles might lay
> hidden there. In a way they are even right about that stance. ;-)
>
> Regarding id being a property or not, here is how I perceive it, as a
> javascript hacker (to pick some trait that felt potentially relevant).
> All the data I enter into a system is in some way a property of it,
> and dynamic reflection (I'm a bit too far into the night to be really
> sure I'm using comp.sci terms properly now, though, so tune your blur
> filter appropriately :-) is often more useful than data hiding.
>
I do not feel the id should be treated as a property because it
overloads two roles---that of naming an object and that of saying
something about the object. id's need to be a way to uniquely specify
an object, and relying on those ids having a specific semantics (eg, the
id is the addr of the object) is asking for trouble later. For example,
when i first started my dance video exhibit I used the title of the
dance as the id, but then I discovered there were several videos of the
same dance, and had to modify my ids plan to account for that.
Fortunately, I had a separate "label" property to hold the title of the
dance. So, the id was able to change to be anything I wanted. Also as
i mentioned above, it makes it easier to merge in new data.
>
> Maybe I'm not quite attuned to how to best organize data yet, but I
> was sort of assuming I might not have to think so hard about it, given
> the "your data, your mess, your problem" philosophy mentioned. (And it
> felt to me like id:s would be part of that. :-)
>
> I'm still not sure I've fully taken in the scope of those id:s being
> the *only* property that discerns between two different items in the
> system, though; I would have felt much more comfortable in an
> environment where items were compartmented into separate id namespaces
> by item type. Not having that still feels somewhat wrong to me, though
> it has not yet been a practical issue. I guess I'll have to start
> employing id tagging techniques once I move into Book and People items
> or the like. And then I can buy that you'd rarely want to see the id:s
> themselves.
>
Remember, IDs can just as easily be things like "32oii", "r23t584hf",
and so on. Their just a hook on which to hang all the properties we
actually care about.
> ...Almost. ;-) (Still very useful for debugging and developing an exhibit!)
>
>
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general
