|[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.
> 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
While that solves this postalAddress problem, would you somehow force
use this "in-line" approach? There might be a good reason for
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
If we allow the expressiveness of RDF to describe the Context, then I
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