[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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.

>>> Greg Byrd gbyrd@xxxxxxxx> 8/21/06 7:50 AM >>

>> 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.)


higgins-dev mailing list