W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2009

Re: [TF-PP] Document now in CVS

From: Ivan Herman <ivan@w3.org>
Date: Tue, 24 Nov 2009 11:04:51 +0100
Message-ID: <4B0BAFC3.6030305@w3.org>
To: Andy Seaborne <andy.seaborne@talis.com>
CC: SPARQL Working Group <public-rdf-dawg@w3.org>
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
  ex:A ?r ?x .
  ?r rdf:type rdfs:ContainerMembershipProperty .

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


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



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

Received on Tuesday, 24 November 2009 10:05:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:57 UTC