Re: Entailment document: Property Path

On 2 May 2011 09:57, Olivier Corby <Olivier.Corby@sophia.inria.fr> 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
>



-- 
Dr. Birte Glimm, Room 309
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283520

Received on Monday, 2 May 2011 22:25:07 UTC