W3C home > Mailing lists > Public > public-owl-wg@w3.org > April 2008

RE: intendedProfile (proposal for ISSUE-111)

From: Boris Motik <boris.motik@comlab.ox.ac.uk>
Date: Wed, 23 Apr 2008 10:02:05 +0100
To: "'Sandro Hawke'" <sandro@w3.org>, <public-owl-wg@w3.org>
Message-ID: <003301c8a520$b4215900$7212a8c0@wolf>

Hello Sandro,

The first part seems fine and I like it; I wasn't sure about the second part.

At the RDF level, we need just two profiles: OWL Full and OWL-R Full. All other profiles are syntactic: they restrict what you can
say rather than how to interpret a certain ontology. The problem is that OWL-R Full is (the only) semantic, and not a syntactic
profile; therefore, one needs to change the consequence relation here.

Similarly, DL-safe rules are new syntax, which you can always interpret in a special way. Therefore, it doesn't seem to me that we
need a special switch that says "yes, use DL-safe rules": if the DL-safe rules are in the knowledge base, this is a distinct piece
of syntax that we use in a way that is prescribed for this syntax.

It might be that I misunderstood some of your points here, so we can discuss this more in the teleconf.



> -----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, 23 April 2008 09:03:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:04 UTC