Re: accessingCollections: postpone due to lack of design/implementation experience?


In our implementation experience o:item triples
are inferred triples constrained by

{?S rdf:first ?X} => {?S o:item ?X}.
{?S rdf:rest ?B. ?B o:item ?X} => {?S o:item ?X}.

So it relates things to lists (for instance running
OWL test manifest we have 824 occurences of o:item)
and same items are indeed in all nested lists (or
eventually in other lists, as RHS could rebind).
I wished it was owl:item (as it is in DAML+OIL)..

Thus far I haven't found a motivationg test case
to use N3/Turtle collection ( ) notation in q:where
clauses of QL, but I do have many cases where ( )
is used in q:select clauses.

Jos De Roo, AGFA

"Seaborne, Andy" <>
Sent by:
01/02/2005 10:26
Please respond to andy.seaborne

        To:     Jos De_Roo/AMDUS/MOR/Agfa-NV/BE/BAYER@AGFA
        cc:, RDF Data Access Working Group <>,
        Subject:        Re: accessingCollections: postpone due to lack of design/implementation 


Nice example!  I couldn't be sure whether the property o:item relates a 
to its members or it relates an item to the intersection or union.

If it's the approach of an inferred triple, like rdfs:member except for
collections, relating list to member:

For ("x" "y")

_:b1      rdf:rest  _:b2 .
_:b1      rdf:first  "x" .

_:b2      rdf:rest  () .
_:b2      rdf:first  "y" .

isn't "y" is a member of two lists? the one starting a _:b1 and the one
starting at _:b2 because a tail of a list is itself a list.  Your example 
work, I think, because it looses the duplicate solution sublist as ?L is 
head of the whole list but other queries ("find all the lists and their 
members") will create unhelful solutions if o:item runs object to subject 
well subject to object.

This approach doesn't geneate a requirement on SPARQL as far as I can see 
although nice syntax would be nice.  Do you think it has an impact on the 

If the former definition of o:item, relating intersection or union to its
members, then it is in the style of using additional information, over and
above that of the collection itself.  Again, I don't think it impacts the
SPARQL design other than possible syntax.  Do you see a requirement of 

                 Andy wrote:
> wait a minute..
> here's a test case I was actually working on (and which is running right 

> now)
> given 
> [ :operator     :RXPelvisOfHipInjury;
>   :precondition [ owl:intersectionOf ( :ConfirmNonPregnancy 
> :PhysicalExamOfHipInjury ) ];
>   :action       [ owl:intersectionOf ( :CADMeasurement :Diagnosis ) ];
>   :effect       [ owl:unionOf ( :InsertHipBolt :ReplaceHip 
> :RevalidationOfHipContusion ) ] ].
> then I would really like to see the query equivalent with
> [] q:select {?X :andStep ?Y};
>    q:where  {?S :operator ?X; :effect ?A. ?A owl:intersectionOf ?L. ?L 
> o:item ?Y}.
> [] q:select {?X :orStep ?Y};
>    q:where  {?S :operator ?X; :effect ?A. ?A owl:unionOf ?L. ?L o:item 
> ?Y}.
> returning
> :RXPelvisOfHipInjury :orStep :InsertHipBolt. 
> :RXPelvisOfHipInjury :orStep :ReplaceHip. 
> :RXPelvisOfHipInjury :orStep :RevalidationOfHipContusion. 

Dan Connolly wrote:
> While the lack of support for accessing collections has been
> noted in various places, we didn't identify it as a requirement
> (or even an objective) in .
> If anybody now thinks it's a v1 requirement, speak now or
> forever hold your peace.
> It's also in order to share design ideas.
> But assuming no lightbulbs go off in such a way as to
> gain consensus, due to lack of design/implementation experience
> I propose we postpone this issue.

Received on Tuesday, 1 February 2005 11:35:22 UTC