Re: Entailment document: Property Path

On 02/05/11 23:24, Birte Glimm wrote:
> On 2 May 2011 09:57, Olivier Corby<>  wrote:
>> A remark concerning the section below :
>> 9 Entailment Regimes and Property Paths (Informative)
>> ...
>> Since property paths are evaluated without entailment, the evaluation under
>> an entailment regime can yield counter-intuitive results. Assuming the use
>> of the RDFS entailment regime and the query
>> SELECT * WHERE { ?s (ex:p3+) ?o }
>> over the above given example data, the result is empty. Although the data
>> contains ex:b ex:p2 ex:c and ex:p2 rdfs:subPropertyOf ex:p3, which under
>> RDFS entailment implies ex:b ex:p3 ex:c, this fact is not used since the
>> arbitrary length path expression ex:p+ is evaluated with simple entailment,
>> i.e., via subgraph matching on the input data.
>> Some systems may compute and record RDFS entailments before query processing
>> occurs. In this case, enumerating ex:p3 edges would return entailed edges as
>> well and hence ex:p3+ would have a solution.
> Well, entailment regimes have been specified independent of the
> implemntation technique, e.g., you don't have to materialize or can
> only materialize some triples, while handling others via query
> rewriting say or computing on-the-fly. Materialization works fine as
> an implementaion techniques, but property paths can expose this. We
> cannot keep using standard entailment relations for property paths
> though since entailment is not defined for path expressions. Thus,
> property paths and entailment together can be a complicated business.
> Should we then write systems may or may not return ex:p3 and declare
> the behaviour of a system that does entailement undefined for queries
> with property paths?
> Birte
>> Olivier

In order to integrate with entailment, all property path evaluation 
comes down to looking for triples in a graph as part of the ALP 
function.  So for RDFS they shouldn't that be the same?


Received on Tuesday, 3 May 2011 06:30:15 UTC