Re: [TF-PP] Document now in CVS

Andy Seaborne wrote:
> 
> 
> On 23/11/2009 11:01, Ivan Herman wrote:
>> Hi Andy,
>>
>> nobody reacted until now... But we should thank you in the first
>> place!:-)
> 
> Thanks!
> 
>> There is still a pending issue in my mind on whether property paths can
>> handle list elements properly or not. The issue I see is to be able to
>> query list elements in their 'natural' order.
> 
> When we had the strawpoll[3], the results [4] didn't suggest much
> support for considering paths with lengths and much against.  I suppose
> the subcase of length of * matching might be easier (not sure) but we
> still have the case of multiple paths to the same RDF term if a list
> contains the same term twice which is a big difference in approaches.
> 
> [3]
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JulSep/0439.html
> [4]
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009OctDec/0055.html
> 

I think the issues in the poll went a bit beyond that... The subcase of
getting access to the length of the match is probably more manageable.

I am not too much worried about the multiple paths case: we can simply
declare that this case is undetermined, or we can say that it is
minimum/maximum of the paths. I believe for the use cases when there is
a need for the length (like the authors' list I referred to) the path is
unique.


> 
> <Digression>
> 
> The underlying issues are, as I see it:
> 
> 1/ A significant amount of list use is for closed sets (c.f. OWL) where
> order does not matter.  Indeed, order gets in the way.
> 

I am not sure I agree. It is true for OWL but, in many cases, I have the
impression of a self-fulfilling prophecy here. I guess I have made this
comment before: in many cases vocabularies are defined as to avoid using
lists, though it would be the proper modelling option exactly because
the authors know that SPARQL cannot properly query the order. See for
example the chapter on "RDF Features Best Avoided in the Linked Data
Context" in the "How to Publish Linked Data on the Web" tutorial of
Chris and friends[1]:

[[[
You should think twice before using RDF collections or RDF containers as
they do not work well together with SPARQL. Does your application really
need a collection or a container or can the information also be
expressed using multiple triples having the same predicate? The second
option makes SPARQL queries straight forward.
]]]

>From a modelling point of view I think this advice is wrong, though I
understand why it ended in the tutorial. And this is only one example.

For containers, the RDFS entailment possibility gives a way to express
what we want. The result may be that people will begin to use those over
collections which is again not optimal...

[1] http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/#datamodel


> 2/ To do it properly, structures (list, set, bag, map?, multimap - map
> less so as we have multiple property values) need to be 1st class
> objects, in SPARQL at least, if not RDF, and treated the structures as
> structures, not encoded in triples.  The triple encoding can be done
> wrong and also obscures the real intent, although that is partially
> because we only have lists (containers not being very popular).
> 
> Using property functions:
> 
> http://www.openjena.org/ARQ/rdf_lists.html
> 
> ?list list:member ?member
> ?list list:index (?index ?member)
> ?list list:length ?length
> 
> puts lists closer to being 1st class.
> 

I think this was one of the features that were rejected, and did not
even make it to the time-permitting features. Ie, let us consider that
as water under the bridge...:-(

> </Digression>
> 
>> I have digged up some mails from early discussions[1][2]. You
>> proposed[1] a scheme whereby
>>
>> SELECT ?paper ?author
>> WHERE {
>>      ?paper ex:authors ?l .
>>      ?l rdf:rest*{?len}/rdf:first ?author .
>> }
>> SORTED BY ?len
>>
>> (or something similar) would work to
>>
>> would work to give back the author's list in list order. Orri had a more
>> complex scheme[2] in his mail...
> 
> If someone wants to work on that ...
> 

I am not really good with the grammar nor with the implementation of
paths. But, well, from a query point of view isn't it enough to allow
for a {variable} to appear right after '*' or '+' in a path and having
it referred as an integer?

> 
>> I believe something like that is really necessary for '*' and '+';
>> handling lists is one of the big outstanding features in my view and not
>> handling them via paths would be a real shame...
> 
> We can handle their use as closed sets which is a step forward.
> 

True but, well, in my opinion it does not solve the bigger issue...

Ivan

>     Andy
> 
>>
>> Ivan
>>
>>
>> [1]
>> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JanMar/0102.html
>> [2]
>> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JanMar/0116.html
>>
>>
>> Andy Seaborne wrote:
>>> I've moved the document from the wiki into CVS, and used xmlspec.
>>>
>>> http://www.w3.org/2009/sparql/docs/property-paths/Overview.xml
>>>
>>> It does not look very nice - we need to settle on a "house style"
>>> (tables, examples, grammars) although I see something emerging in
>>> sparql.xsl.
>>>
>>>      Andy
>>>
>>

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf