Re: [TF-ENT] Entailment regimes doc update

Hey Birte,

On 2010-2-17 15:48 , Birte Glimm wrote:
[snip]

> 
>> More substantial comment:
>>
>> I must admit I am a bit bothered by 5.2.1. I understand what is
>> happening but I am bothered anyway:-( I am afraid that it will become
>> fairly difficult for an average OWL RL user to follow what is happening
>> (and an average OWL RL user may not understand all the details and
>> intricacies of all this). Eg, if I look at
>>
>> SELECT ?r WHERE { ex:a ?r ex:a }
>>
>> for the data
>>
>> [[
>> ex:a ex:b ex:c .
>> ex:w ex:ww 123 .
>> ex:z ex:zz 123 .
>> ]]
>>
>> then ?r/owl:sameAs will be the result. This is because the dt-eq will
>> bring owl:sameAs into the picture through the back door of the rule set.
>> As a consequence, eq-ref will produce the (ex:a owl:sameAs ex:a) triple
>> and due to dt-eq (C2) will not apply.
> 
> I agree with the not nice/counterintuitive side effect, but I don't
> think you'll get ?r/owl:sameAs as answer because the variable binding
> owl:sameAs does not occur in the input/the scoping graph and also does
> not occur in the implicitly present axioms that are assumed to be any
> OWL 2 ontology. However, if you add ex:somethingelse owl:sameAs
> ex:somethingelse, which is not really related to any of the previous
> triples and not saying much, then you will get owl:sameAs as solution
> for the same query.

Oops, I am sorry, you are right. The datatypes do not make it but the
other 'sameAs' triple trivially does. Sorry. And it does not make me
less unhappy:-)

> 
> I think you assume that we look at the saturation, i.e., I take the
> input, then I run all the rules exhaustively, and whatever I find
> there I take to be the "allowed" values. This means that in order to
> get systems have the guaranteed same results on a query, we are fixed
> to that rule set, which is not so nice.
> 

Well, not nice indeed, though, well, this is part of the (normative!)
part of the OWL 2 RL... Ie, it is not that bad. What bothers me is
rather that it would be RL specific and, after all, the same issue
arises for the more general OWL 2 Full case.

> I see two possibilities to reduce the number of counterintuitive side
> effect. We need something to prevent infinite answers, which dome from
> axioms containing rdf:_1, rdf:_2,... and from datatypes (in particular
> for OWL Full with owl:topDataPropery or numberRestrictions), and from
> inconsistencies.
> In order to handle all these cases, it would be nice if we can always
> assume that query results are always taken from a finite
> signature/vocabulary. This signature/vocabulary at the moment contains
> only the input, but one possibility would be to also add, for example,
> the reserved vocabulary of the language minus rdf:_1, rdf:_2, ...
> In that case, owl:sameAs would always be assumed to be present because
> it is part of the reserved vocabulary, while you still  have a
> guarantee of finite answers. In the RDF(S) case, that will give you
> always lots of axiomatic triples, but not those of the form
> rdf:_1 rdf:type rdf:Property.

I think this would certainly be much more intuitive then the current
version.

But I am not sure why that would give me lots of axiomatic triples. The
only thing we would say is that the vocabulary of RDF(S)/OWL occurs in
sk(SG), additionally to whatever is put there but the normal processing.
What I mean is something like:

(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?

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

> 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