| [higgins-dev] in-line attribute values (was: [IdAS] filter language: XPath/SPARQL) |
|
<referring to below>
>While that solves this postalAddress problem, would you somehow force
>providers to use this "in-line" approach? No, I was also asking from the POV of a CP. If we can inline this stuff for LDAP, we will -- it fits the model better.
Jim
>> Question 3: In the example, hasPostalAddress is a separate object. >> > <skip> > > XPath doesn't let us do this (effectively dereference a pointer to > another element) -- this is what prompted me to ask #3 (alternate > representations) in > http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg00583.html > > While that solves this postalAddress problem, would you somehow force providers to use this "in-line" approach? There might be a good reason for representing postalAddress as a separate object -- e.g., if multiple subjects share the same address, then one could change that address in one place, rather than in each subject. (And what if the address has an element that points back to a set of "inhabitants"? Can't be in-lined because of its circular structure.) If we allow the expressiveness of RDF to describe the Context, then I don't believe we should then restrict the kinds of graphs that can be represented. (I'm not saying that you're advocating this, Jim.) ...Greg _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |