Re: [TF-ENT] OWL Direct Semantics added

Ok. So pre-supposition on (a) may be wrong (though we may have to have
this in writing somewhere, just to make it clear. I believe we would
have to have some separate conformance clause/document somewhere...).

But, if it is, then I do not see any real options than to have what you
have in the documents. But it is ugly:-(

Ivan

Birte Glimm wrote:
> Thanks for the comments Ivan.
> 
> 2009/11/24 Ivan Herman <ivan@w3.org>:
>> Hi Birte,
>>
>> I share your unhappiness:-)... and I am wondering. I am not sure we
>> discussed how a user would choose among the various entailment regimes a
>> system provides (maybe different URI-s correspond to different
>> regimes?). Also, I am not sure about a conformance issue: would all
>> SPARQL implementation have to implement simple entailment as a minimum?
>>
>> However... let us suppose that (a) each system has simple entailment as
>> a possibility and (b) the user can choose which entailment is used for a
>> specific query. Do we then really need this mixed semantics? What are
>> the use cases? After all, the user can then choose to run simple
>> entailment for queries on annotations...
> 
> For (a) I don't think simple entailment is required, at least I don't
> read that from the spec. And, if the spec doesn't force me to I would
> most likely not extend my reasoner to work with simple entailment. We
> do not even get to see any triples since we parse with the OWL API and
> work only with the OWL API objects that reflect the ontology
> structures as also found in FSS. Pellet so far also has no support for
> simple entailment I think and it requires quite different algorithms
> and data structures than (hyper)tableau algorithms commonly ued for
> OWL Direct Semantics (DS) reasoning. The spec now requires for OWL DS
> that the systems have to do some simple entailment, but you would only
> have to work with those triples that represent non-logical things.
> Thus, you can get away with an unoptimised simple implementation since
> only few triples have to be treated with simple semantics. Otherwise,
> it is probably better to use a third-party triple store for simple
> entailment.
> 
> Similarly for (b). I don't see that we have anything in place so that
> the user can control what entailment is used. So far, a system can
> declare in its system description that it uses some entailment regime.
> We have no official way to announce mixed entailment regimes for a
> data set, i.e., I cannot say my data set contains graph g1 and simpe
> entailment will be applied to g1 and it also contains g2, which is as
> g1, but OWL DS entailment will be employed. Even if I could say that,
> it would be up to me to offer two enailment regimes for the same
> graph. There is also no way to indicate in the query itself what
> entailment you would like to have as a user.
> 
> If we assume that such a choice would be added (either now or maybe in
> a future spec), then I guess we can just use direct semanics (no
> combination of semantics). If users want to combine results and there
> is a way to specify the entailment regime to be used in the query,
> then users could use union queries.
> If there is at least a way so that you can issue a query once with
> simple and once with another entailment regime, one could also leave
> it to third party tools to implement something with a kind of combined
> semantics. Such a tool could split the query up into simple semantics
> parts and direct semantics parts, then issue queries for the two parts
> separately, and then assemble the results. E.g. if I want to know
> whether there is any annotation assertion assigning a label to an
> individual that is the same as :Birte, I could query
> SELECT ?label WHERE { ?ind owl:sameAs :Birte . ?ind rdfs:label ?label . }
> and the owl:sameAs reasoning is done with DS, while the annotation
> assertion is then looked-up wth simple semantics.
> 
>> I presume you guys discussed that...
> 
> It is a sword hanging over us and entailment regimes alone cannot
> solve that. We should probably try and bring it up for discussion in
> the whole group. It seems, however, that annotations for OWL DS is the
> only real problem. For all other things, you can just say the system
> describes what it offers and that is what the user gets. If the system
> says it does RDFS, then you get RDFS. If the system offers data sets
> with some graphs used with simple entailment and others with, say,
> RDFS entailment, then it can be described in SDs, but it is not
> officially specified how to describe that. Then you can choose the
> graph that uses the entailment that you want. I am not sure whether
> there is general support from the WG for letting the user ask for
> something that the system did not advertise it would do.
> 
>> A tiny editorial issue, too. You write:
>>
>> [[[
>> SPARQL is only defined for basic graph patterns that can be instantiated
>> into RDF triples. For OWL 2 Direct Semantics, an extension to BGPs in
>> functional style syntax (FSS) or other popular OWL syntaxes seems
>> natural, but is not part of this specification.
>> ]]]
>>
>> though I understand the intention, I am not sure this is editorially
>> correct. Isn't it correct that anything that I write down in FSS can be
>> expressed in RDF graphs (even if it is ugly:-)? If so, the issue is not
>> with BGP-s or an extension thereof, but the triple-based syntax used in
>> the BGP and a possibly alternative based on, say, FSS. Ie, something like
>>
>> [[[
>> SPARQL is only defined for basic graph patterns using a triple-based
>> syntax. For OWL 2 Direct Semantics, an alternative syntax for BGPs based
>> on functional style syntax (FSS) or other popular OWL syntaxes seems
>> natural, but is not part of this specification.
>> ]]]
> 
> Changed to use your wording. Thanks for the suggestion.
> 
> Birte
> 
> 
>> I may have got something wrong...
>>
>> Ivan
>>
>> Birte Glimm wrote:
>>> Hi all,
>>> I have added a section about OWL Direct Semantics:
>>> http://www.w3.org/2009/sparql/docs/entailment/xmlspec.xml
>>>
>>> I am not really happy with the work-around for querying for
>>> annotations, but it seems users really want to query for them and
>>> Direct Semantics simply ignores annotations. I am happy about any
>>> feedback/alternative suggestions for that and for any other parts of
>>> the section.
>>>
>>> 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
>>
> 
> 
> 

-- 

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