W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2009

Re: [TF-ENT] OWL Direct Semantics added

From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
Date: Tue, 24 Nov 2009 17:05:49 +0000
Message-ID: <492f2b0b0911240905v54b1e5b0rd0b473f70692fdb7@mail.gmail.com>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
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
>



-- 
Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283529
Received on Tuesday, 24 November 2009 17:06:21 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:40 GMT