W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2012

Property Paths and Entailment

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Tue, 14 Feb 2012 13:08:34 +0000
Message-ID: <4F3A5CD2.2000106@epimorphics.com>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
Axel wrote:
> Just for completeness and not to forget:
>
> Birte's mail [1] indicated that marking Property paths informative/non-normative could also be
> considered, also because of the things that remained unclear wrt. entailment regimes [2].

> 1. http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0128.html
> 2. http://www.w3.org/TR/sparql11-entailment/#property-path
> 3. http://www.w3.org/2009/sparql/meeting/2012-02-07#line0084

I don't see that the argument that some entailment regimes have problems 
with property paths is altered by the recent comment on complexity.

The problems exist regardless of distinct/counting semantics.  I don't 
think anything is unclear; it is just not a smooth integration in the 
presence of transitive inferences but that is a rather different matter.

The use of transformations to define property paths was, in part, to 
maximise the applicability to as wide a range of entailment regimes as 
possible.

Rather than take something out of the normative main query document, it 
should be the entailment regimes doc that modifies the view of query. 
For example, make a syntactic restriction on queries to exclude property 
path forms unsuitable to the regime.  e.g. forbid * (and others) in the 
"Legal Queries" section of the entailment regime or indeed anything that 
isn't a transformable form so any property path that generates 
ZeroLengthPath, ZeroOrMorePath, OneOrMorePath, or NegatedPropertySet.

BTW [2] is out-of-date.  * isn't defined as {0} UNION +  It was at one 
time, it isn't now.  The algebra operator names have changed.

	Andy
Received on Tuesday, 14 February 2012 13:09:06 GMT

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