RE: intendedProfile (proposal for ISSUE-111)

Hello,

I do agree that some way of specifying the intended semantics would be good. It might be good, though, to keep things at a
declarative level. Thus, we might add another annotation property, called owl:intendedSemantics, with the following values:

- owl:OWL-Full would mean "use the OWL Full semantics to interpret the document"

- owl:OWL-R-Full would mean "use the OWL-R Full semantics to interpret the document"

- owl:DL would mean "use the OWL DL semantics to interpret the document"


These values would thus declaratively define the set of consequences of a particular ontology. How this is to be achieved in tools
is an implementation issue. For example, a DL reasoner might try to transform an owl:OWL-R-Full ontology in an appropriate way to
provide exactly the required set of consequences; an OWL-R-Full reasoner might simply serialize an OWL DL ontology into an RDF graph
and apply the desired semantics. The combinations are endless; however, the point is that we just specify what the desired result
is, but not how to get there.

If owl:intendedSemantics is not present, or if an ontology imports another ontology which has a different intended semantics, then
we might say that the intended semantics is not defined. It is up to tools to provide a warning to the user or do whatever they deem
necessary to fix this problem.



Note that owl:OWL-Full, owl:OWL-R-Full, and owl:DL thus select the appropriate consequence relation. Now here is why I believe that
we don't need owl:EL++, owl:DL-Lite, and owl:OWL-R-DL values: in the case of all these profiles, the consequence relation does not
differ; it is the syntax that is different. An ontology is in EL++ if it does not use syntactic constructions outside this fragment;
its meaning is defined by OWL DL in precisely the same way as this is the case for the complete OWL DL language.

I do agree that, from a practical point of view, one might want to stipulate that an ontology has been designed as, say, an EL++
ontology. We have two possibilities for handling this:

- We might recognize that this is an orthogonal concern to the choice of the consequence relation. Therefore, we might add a
different annotation property called, say, owl:syntacticFragment.

- We might introduce owl:EL++, owl:DL-Lite, and owl:OWL-R-DL, but say that they are, from the point of view of the consequence
relation, equivalent to owl:DL. We should then say that we merged the actually orthogonal concerns of selecting the consequence
relation and providing hints into one construct due to practical reasons.

Regards,

	Boris


> -----Original Message-----
> From: public-owl-wg-request@w3.org [mailto:public-owl-wg-request@w3.org] On Behalf Of Sandro Hawke
> Sent: 22 April 2008 20:59
> To: public-owl-wg@w3.org
> Subject: owl:intendedProfile (proposal for ISSUE-111)
> 
> 
> 
> Here's a possible solution for ISSUE-111 [1], with some variations and
> discussion.  I was only considering the RDF/XML serialization here.  For
> the XML serialization, a MIME type could a good solution.
> 
> * Basic Approach:
> 
> Use an ontology property.  So the users adds a triple like this:
> 
>   <> owl:intendedProfile owl:DL.
> 
> This would have processing-model semantics, much like owl:imports.  The
> processing model is something like this:
> 
>    1. You fetch the content from some URI U.
>    2. If its Content-Type is "application/rdf+xml", proceed.
>       (otherwise, this procedure doesn't apply; it's not OWL
>       in RDF/XML.)
>    3. Parse it into an RDF graph.
>    4. Look for any triples matching { U owl:intendedProfile ?x }
>    5. If there are zero or >1 distict values for ?x, then
>       this algorithm does not apply.  Fall back to whatever
>       you did before OWL 2.
>    6. If you implement the profile named by ?x, use it.
>       Otherwise, you MAY proceed using some other profile that you do
>       implement, but you SHOULD warn the user about how the results may
>       be different.  (You may be able to characterize, for the user, how
>       the results will be different and ask them whether to proceed.)
> 
> That seems pretty simple, and I don't see any problem with it.  The key
> point is that the failure mode in step 5, which also occurs if you
> eliminate the triple by some kind of RDF entailment, leaves us no worse
> off than we are in the OWL 1 world.
> 
> Some variations....
> 
>    1.  Allow one to specify multiple profiles.  In this sense, they
>        become more like "Features" or "Semantic Extensions" than
>        "Profiles".
> 
>             <> owl:usesSemanticExtension owl:DL.
>             <> owl:usesSemanticExtension owl:DL-Safe-Rules.
> 
>    2.  Perhaps #1 has to be done with an RDF List, since if it were
>        done with just more triples, you wouldn't be able to detect the
>        case where the triple naming some extension was removed.  You'd
>        think you knew the exact intended semantics but would be wrong.
>        I'm not sure if this is a problem -- we don't seem to mind it
>        with owl:imports.   Anyway, if it's a problem, we can do
>        something like this:
> 
>            <> owl:usesSemanticExtensions ( owl:DL owl:DL-Safe-Rules )
> 
>    3.  Call it "imports", or something like "imports".  As a rules user,
>        it seems perfectly natural to me to say that RDF graphs have only
>        RDF Simple Entailment until/unless they "import" various
>        semantics.  I picture import as loading the rulebases which
>        compute entailments under those semantics, but I would expect
>        that in some cases (eg owl:DL) there would be vastly superior
>        implementations that simply recognized the owl:DL URI and turned
>        on their local DL reasoner.
> 
>            <> owl:imports owl:DL  # this ontology uses DL
>            <> owl:imports owl:DL-Safe-Rules    # and also these
>            <> owl:imports <some_std_facts>.
>            <> owl:imports <some_other_ontology>.
> 
> Ideally, one could have an ontology which uses owl:DL and imports
> another ontology which use owl:OWL-R.  My sense is that allowing that
> would complicate matters a lot -- you couldn't just compute the imports
> closure and then hand it off to the reasoner! -- so we probably want to
> make that an Extra Credit thing for now, saying system MAY do that, but
> are also free to simply report an error, that ontologies are being
> combined which use incompatible profiles.
> 
> Oh...   Another idea: users might want to say "at least" OWL DL-Lite.
> 
>       Ontology A:
>            <A> owl:exactSemantics owl:DL.
>       Ontology B:
>            <B> owl:exactSemantics owl:DL-Lite.
>       Ontology C:
>            <C> owl:minimalSemantics owl:DL-Lite.
> 
> Now, A+B could only be run by some very clever (impossibly clever?)
> system which somehow combined A and B keeping their separate intended
> semantics.   Is that even well defined?  I dunno.   Avoid this case.
> 
> But A+C could be handled, no problem, by an owl:DL reasoner.
> 
> ...
> 
> Somewhere in here, it would be nice to tell people they SHOULD NOT (even
> MUST NOT?) rely on the places where these various languages are not
> neatly stacked semantic extensions.  So that, while falling back from
> owl:DL to RDFS semantics obviously makes the reasoning incomplete (with
> respect to the intended DL semantics), the fact that in some corner
> cases it also makes the reasoning unsound..., well, we'd like that not
> to cause real-world problems.
> 
>       -- Sandro
> 
> [1] http://www.w3.org/2007/OWL/tracker/issues/111

Received on Wednesday, 21 May 2008 19:30:40 UTC