Re: [TF-ENT] Entailment regimes doc update

On 2010-2-17 18:29 , Birte Glimm wrote:
> [snip]
[snip again...]

> Always is exaggerated because it depends on the query. I guess my
> dislike of the axiomatic triples made me exaggerate ;-)

:-)

> But if you have a query such as
> SELECT ?ind ?class WHERE { ?ind a ?class }
> and only the triple
> ex:a a ex:C .
> then the query will give you much more than just ex:a and ex:c, e.g.,
> ?ind/rdf:type, ?class/rdf:Property,... and under OWL RDF-Based
> Semantics you also get things such as ?ind/owl:Thing,
> ?class/owl:Class, ....

Hm. Yes, it will give you that.

> Since I am an OWL DL person, my perspective might also be a bit
> blurred in that it seems to me very important to have individuals and
> classes and to be able to derive instances of classes. Overall it is
> probably a better way to go and less confusing for the average case.
> 

Well... I could of course say that if the user wants that, then of
course one could use the DL entailment, right?

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

which is the OWL 2 RL generated triples. Note, b.t.w., that many of
those triples will be filtered out by the modified (C2) because they use
symbols from the xsd vocabulary that would not be part of Vocab. But it
still has a bunch of others...

>> (C2) for each variable x in V(BGP), sk(mu(x)) either occurs in sk(SG) or
>> in Vocab
>>
>> where Vocab is defined separately for RDF(S)/OWL, minus all the rdf:_i
>> elements that do not occur explicitly in SG.
>>
>> 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...

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).

> 
>> (Just to let my fantasy go ahead here, I could imagine the user wanting
>> to have a means to explicitly add some vocabularies to the regime for
>> Vocab. Eg, add the SKOS vocabulary. I am not sure how would one spec
>> that...)
> 
> If the vocabulary has no meaning in the entailment regime, that
> wouldn't give you much, would it? Either I have rules/axioms in my
> input triples that use the vocabulary, in which case the terms already
> occur, or they are not derived anyway because neither the entailment
> regime nor the given axioms give any meaning to the terms. The
> question is only what to do with all the terms that do have a meaning
> already given from the entailment relation and we have, unfortunately
> infinitely many of those.

O.k. I think I see what you mean...

> 
> Maybe that is just the import (implicit import) question that comes up
> again and your fantasy already went from pure terms/vocabulary to
> whole axioms that are being sneaked in ;-) Extending SPARQL Query in
> this direction would be one way to go. 

But not now:-)

>                                         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).

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...

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