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

Re: property paths three more test cases pp13, pp14, pp15

From: Steve Harris <steve.harris@garlik.com>
Date: Tue, 21 Dec 2010 12:18:17 +0000
Cc: Axel Polleres <axel.polleres@deri.org>, SPARQL Working Group <public-rdf-dawg@w3.org>
Message-Id: <AD7D3770-CE1A-4386-83A7-6DD7D7AD7B94@garlik.com>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
Quick summary, I think I get why this is defined this way now. I have some concerns, but don't have a better suggestion.

Comments inline.

On 2010-12-21, at 11:20, Andy Seaborne wrote:
> 
> On 21/12/10 11:12, Steve Harris wrote:
>> On 2010-12-20, at 17:23, Axel Polleres wrote:
>> 
>>> Steve,
>>> 
>>> I added a new use case pp16 along the lines you suggest, see details below.
>>> 
>>> On 20 Dec 2010, at 16:46, Steve Harris wrote:
>>> 
>>>> I think pp14 would be more enlightening if the pp14.ttl included a disconnected foaf:knows graph, and some triples using another predicate. Something like:
>>>> 
>>>> @prefix :<http://example.org/>  .
>>>> @prefix foaf:<http://xmlns.com/foaf/0.1/>  .
>>>> 
>>>> :a foaf:knows :b .
>>>> :b foaf:knows :c .
>>>> :d foaf:knows :e .
>>>> :f foaf:name "test" .
>>>> :a foaf:homepage :h .
>>>> 
>>>> Even after Axel's proposed changes I find the wording a bit impenetrable, though admittedly I haven't had time to study the algebra.
>>>> 
>>>> Axel, can you tell mw what results you'd expect from pp14.rq with that data?
>>>> 
>>> 
>>> your data returns, according to my understanding of the algebra:
>>> 
>>> -------------------
>>> | X      | Y      |
>>> ===================
>>> | :a     | :a     |
>>> | :a     | :b     |
>>> | :a     | :c     |
>>> | :b     | :b     |
>>> | :b     | :c     |
>>> | :c     | :c     |
>>> | :d     | :d     |
>>> | :d     | :e     |
>>> | :e     | :e     |
>>> | :f     | :f     |
>>> | :h     | :h     |
>>> | "test" | "test" |
>>> -------------------
>> 
>> OK, thanks. Intuitively I find the :e/:e, :f, :h, and "test" results odd, but I've not given enough time to trying to understand the usecases.
> 
> One example is:
> 
>   ?x rdf:type/rdfs:subClassOf* ?T

I see, otherwise you'd have to write ?x (rdf:type|rdf:type/rdfs:subClassOf*) ?T, which looks a bit tautological.

On the other hand, trying to find just the transitively closed subclass relationships with:

?C rdfs:subClassOf* ?SC .

you will get many non-sensical results. I think you can write

[] rdfs:subClassOf ?SC .
?C rdfs:subClassOf [] .
?C rdfs:subClassOf* ?SC .

if you want just the transitively closed classes/superclasses, but that also looks odd.

I'm also concerned that the relatively innocuous-looking expression like { ?s rdfs:subClassOf* ?o } will have a higher cardinality than { ?s ?p ?o }, but I guess users will learn not to do that after the first few hundred times they try it :)

- Steve

> which is
> 
>   ?x rdf:type ?Z
>   ?Z rdfs:subClassOf* ?T
> 
> Under RDFS:
> 
>  <C> rdfs:subClassOf <C>
> 
> If you are writing that over plain data, you need "a rdfs:subClassOf* a" (the {0} case) to get the subclass effect or a more complex query.
> 
> 	Andy

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD
Received on Tuesday, 21 December 2010 12:18:53 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:44 GMT