[snip]
>> 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:
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, ....
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.
> (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.
> (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.
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. 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.
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
>
>
--
Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283529