We can also make "id" a read-only property. I like escape hatches. :-)
Yes, I do adhere to the "your data, your mess, your business" philosophy. I think the "one ring to rule them all" philosophy (ref. Lord of the Rings) is a bad idea (replace "ring" with format, schema, uber ontology). David 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. > > 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. > > 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. > > ...Almost. ;-) (Still very useful for debugging and developing an exhibit!) > _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
