Property Paths and Entailment

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 UTC