Re: [TF-ENT] Entailment regimes doc update

[snip]
> But yes. Many extra triples are generated for this case. I used my own
> OWL 2 RL stuff
>
> http://www.ivan-herman.net/Misc/2008/owlrl/
>
> to generate
>
> http://tinyurl.com/ygtuodk

That's a nice little tool. I knew you had it, but I hadn't seen the
web interface before.

>>> Wouldn't that work? Would that bring in so many extra triples?
>> Better than before I guess.
>
> You do not seem to be convinced:-( And you are probably right...

I am not 100% happy. I think it is better because I can imagine tools
that allow you to choose between getting all triples and getting only
those that use the input vocabulary. Thinking even more about this,
here is another refinement that might capture even better what most
users would expect.
(C2) For each variable x in V(BGP), sk(μ(x)) occurs in sk(SG) or in Vocab.
(C3) For each triple s p o in P(BGP), either s or o occurs in sk(SG).

Here, C2 is very lax and it allows almost all axiomatic triples, but
still guarantees finiteness of the answers in all cases. Now C3
basically says that if the instantiated BGP has nothing to do with
your data, then omit it. I omit the predicate as an option in C3
since predicates such as rdf:type occur in most graphs (possibly by
implicit triples as in OWL) and will then let through most axiomatic
triples. Answers that are then filtered out are basically axiomatic
triples that you didn't mention at all. This could be relaxed to (not
sure which one makes more sense, needs more thinking)
(C3) There is at least one triple s p o in P(BGP) such that either s
or o occurs in sk(SG).

Going back to the examples, if we have the query:
SELECT ?ind ?class WHERE { ?ind a ?class }
and data:
[[
ex:a a ex:b .
]]
as in you generated output, then you would get under OWL RL
?ind/ex:a, ?class/ex:b

For the query
SELECT ?r WHERE { ex:a ?r ex:a }
over
[[
ex:a ex:b ex:c .
]]
you would get
?r/owl:sameAs
no mater whether there is ex:something owl:sameAs ex:something or not.

It is still possible to generate artificial examples, but less so. E.g.,
SELECT ?type WHERE { rdf:type a ?type }
over the empty graph gives you nothing since C3 cannot be satisfied in
an empty graph. If we query over
[[
ex:b a ex:c.
]]
we get
?type/rdf:Property
C2 holds because rdf:Property is in vocab (assuming we do RDF(S) entailment)
C3 holds because the instantiated BGP is rdf:type a rdf:Property and
the subject rdf:type occurs in its abbreviated form in your data. That
seems a nicer compromise. If we don't exclude axiomatic triples, we
get infinite answers, and if we exclude some, we get some non-local
side effects, but that cannot be totally avoided.

> Well... this is clearly not our decision. To be formal, we should
> definitely flag that as an issue to be discussed. In some ways, the
> question is: is it better to have many potential responses (ie, the user
> will have to filter things out) or a small number though some expected
> results will not be returned (only via ugly tricks).

Yes.
I would prefer better too many than too few. Tools will hopefully
provide a way to be configured such that they hide what I don't want
to see, while still giving me the chance to see it if I want to.

[snip]
>>                                         Another would be to define
>> something like "extensible entailment regimes", where the entailment
>> regime is a combination of one of the defined semantics plus some
>> rules/axioms that the endpoint will always apply, e.g., the SKOS
>> axioms are always assumed to be present.
>
> I think the answer is: this is where RIF comes in. That gives me the
> necessary flexibility (and I can always simulate OWL 2 RL level with a
> RIF rule set).

Yes. That would be nice.

> B.t.w.: a point here for the future RIF discussion:
>
>  - we have something for OWL 2 RL
>  - we will have something for RIF (hopefully)
>  - there is a RIF document that, essentially, defines a RIF rule set for
> OWL 2 RL
>
> Surely the result of the entailment should be the same whether I use the
> OWL 2 RL entailment definition or the RIF one and use the official rule
> set...

Yes. It would be not nice at all if that were not the case.

Cheers,
Birte

> Cheers
>
> Ivan
>
>> Birte
>>
>>>> We might still want to exclude axiomatic triples unless they occur in
>>>> the input because they potentially add lots of answers that you don't
>>>> really want.
>>>
>>> See above. But if I am wrong, I do not mind that either.
>>>
>>>> Another possibility would be to apply C2 only to variables in subject
>>>> and object position and allow anything in the predicate position. That
>>>> still can cause counterintuitive side effects, but many more cases are
>>>> covered. In that case, inconsistencies need extra care because in
>>>> principle this would still allow infinite answers if the given graph
>>>> is inconsistent and we just assume the scoping graph to be equivalent
>>>> to the queried graph no matter what.
>>>
>>> I guess you had that in one of the first drafts and we did not really
>>> like it:-(
>>> [snip]
>>>>>
>>>>> Sigh.
>>>>
>>>> Sigh too.
>>>
>>> :-)
>>>
>>> Ivan
>>>
>>>> Birte
>>>>
>>>>>
>>>>> Ivan
>>>>>
>>>>> [1]
>>>>> http://www.w3.org/TR/2009/REC-owl2-rdf-based-semantics-20091027/#Appendix:_Axiomatic_Triples_.28Informative.29
>>>>> [2]
>>>>> http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Entity_Declarations_and_Typing
>>>>>
>>>>>
>>>>>
>>>>> On 2010-2-16 18:42 , Birte Glimm wrote:
>>>>>> Hi all,
>>>>>> I have committed a new version of the entailment regimes document:
>>>>>> http://www.w3.org/2009/sparql/docs/entailment/xmlspec.xml
>>>>>>
>>>>>> There is now a description of the OWL RDF-Based Semantics incl. the
>>>>>> OWL 2 RL profile. The OWL 2 RL profile can also be used with Direct
>>>>>> Semantics, so I have added that there too. Further I have added a
>>>>>> section about aggregates with RDF(S) entailment, addressing at least
>>>>>> parts of Axel's comments (no owl:sameAs discussion yet for
>>>>>> aggregation). I also defined the behaviour for inconsistent graphs
>>>>>> more clearly because the previous spec didn't define the scoping graph
>>>>>> in the case of inconsistencies. It was rather assumed that the scoping
>>>>>> graph is still equivalent to the active graph, so that systems can
>>>>>> just use the graph as is modulo bnode renaming, but that allowed
>>>>>> infinite answers for inconsistent graphs. I now use Axel's suggestion
>>>>>> for condition C2 and require not only bindings for variables inn
>>>>>> subject position to occur in the input, but require this for all
>>>>>> variables. This also solves the OWL RDF-Based semantics problem where
>>>>>> you can have infinite answers from owl:topDataProperty, which relates
>>>>>> an individual to all data values. Now all RDF-Based regimes (RDF,
>>>>>> RDFS, OWL 2 RDF-Based (for OWL Full and OWL RL)) use the same
>>>>>> definitions, which is nice IMO.
>>>>>>
>>>>>> Birte
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Ivan Herman, W3C Semantic Web Activity Lead
>>>>> Home: http://www.w3.org/People/Ivan/
>>>>> mobile: +31-641044153
>>>>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>>>>> FOAF   : http://www.ivan-herman.net/foaf.rdf
>>>>> vCard  : http://www.ivan-herman.net/HermanIvan.vcf
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>>
>>> Ivan Herman, W3C Semantic Web Activity Lead
>>> Home: http://www.w3.org/People/Ivan/
>>> mobile: +31-641044153
>>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>>> FOAF   : http://www.ivan-herman.net/foaf.rdf
>>> vCard  : http://www.ivan-herman.net/HermanIvan.vcf
>>>
>>>
>>
>>
>>
>
> --
>
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF   : http://www.ivan-herman.net/foaf.rdf
> vCard  : http://www.ivan-herman.net/HermanIvan.vcf
>
>



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

Received on Wednesday, 17 February 2010 20:12:48 UTC