Re: [TF-PP] Document now in CVS

Just a quick note (I know I do not answer to all questions...):

Andy Seaborne wrote:
> 
>>>
>>> <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.
>> ]]]
> 
> I'd say that was good advice about lists generally, not SPARQL specific
> - they don't work with inference because they are encoded in triples,
> mixing syntax and structure.
>

Well, that may be true but let us not digress too far:-)


>>> 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.
> 
> Other examples?  Can you gather a comprehensive set of examples? That
> would scope the space so we know what implications the design decision
> will have.
> 

The problem is that these are negative examples that are difficult to
gather! I mean: how could one find out how many cases we have when lists
were deliberately ignored _because_ SPARQL cannot handle them? That is
an almost impossible tasks, it would mean going through mailing lists...

A positive example for List usage, though, is the bibliography
ontology[1] which has an authors' list with range being list or Seq.
That means that querying the proper author list in SPARQL become a pain
(and academic authors may be _very_ sensitive on the exact order:-). It
is only one, though important example...

[1] http://bibotools.googlecode.com/svn/bibo-ontology/trunk/doc/index.html

>> 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...
> 
> You mean an infered list:member or extended rdfs:member?  Doesn't that
> loose ordering and so is exactly rdf:rest*/rdf:first ?
> 

No. one can do something like:

SELECT ?x  ?r
WHERE {
  ex:A ?r ?x .
  ?r rdf:type rdfs:ContainerMembershipProperty .
} ORDER BY ?r

if the endpoint has RDFS entailment then the returned order will be
fine. Indeed, the RDFS entailment will set ?r to be of type container
membership for all rdf:_i properties...


> 
> It would be great if you would articulate the bigger issue and then we
> can see the amount of work needed in adding to this time permitting
> feature and also generate some consensus on requirements and approach. I
> don't think we are near that point yet.
> 

Yeah, I know...:-(

My bigger issue is simple, in fact: I would like the path design to
cover the use case

http://www.w3.org/2009/sparql/wiki/Feature:AccessingRdfLists

I did not really fight for that one because I had the feeling the path
expression should cover it. I was wrong:-(

Ivan

-- 

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