- From: Ivan Herman <ivan@w3.org>
- Date: Wed, 17 Feb 2010 16:24:14 +0100
- To: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
- CC: SPARQL Working Group <public-rdf-dawg@w3.org>, Chimezie Ogbuji <ogbujic@ccf.org>
- Message-ID: <4B7C0A1E.1090809@w3.org>
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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Wednesday, 17 February 2010 15:21:50 UTC