W3C home > Mailing lists > Public > public-owl-dev@w3.org > October to December 2011

Re: deprecating an axiom

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Thu, 8 Dec 2011 12:02:17 -0500
Message-ID: <CAFKQJ8k05i+sqGupJ1XLGJvqUFBkKUkmoES71b5RF7S4=Mzh8g@mail.gmail.com>
To: Chris Mungall <cjmungall@lbl.gov>
Cc: Owl Dev <public-owl-dev@w3.org>
On Thu, Dec 8, 2011 at 11:30 AM, Chris Mungall <cjmungall@lbl.gov> wrote:
>
> On Dec 1, 2011, at 8:45 PM, Alan Ruttenberg wrote:
>
>
>
> On Thu, Dec 1, 2011 at 1:13 PM, Chris Mungall <cjmungall@lbl.gov> wrote:
>>
>> The OWL2 syntax allows for deprecated classes and properties, although
>> deprecating an entity doesn't change the semantics.
>>
>> Is there a standard way to deprecate an axiom? Would there be a negative
>> consequences in using owl:deprecated, or should this be considered reserved?
>>
>> I have one project in mind, where we are providing provenance for each
>> axiom - a unique identifiers and a pubmed URI. When we remove an axiom we
>> want to keep it around so we don't reuse the same ID or accidentally add
>> back an equivalent axiom. I expect that in order to silence the axiom we
>> will have to keep the axiom in a separate ontology that is never imported
>> during reasoning. I don't think there is a way to keep the axiom annotation
>> around without the axiom (perhaps in OWL full, but I'm not interested in
>> going that way). Another option would be to translate the axiom to an
>> annotation assertion but this would be a bit hacky.
>
>
> I've been thinking that we want a shadow of the OWL vocabulary for use in
> several contexts, including this one, where all the (rdf) predicates were
> annotation properties and and all the the remaining terms were bare URIs.
> Then you could perform the a trivial replacement of, say, namespace, to
> nullify any axiom, with fairly easy modifications to tools for display.
>
>
> I like this as it effectively silences the axiom.
>
> However, I'm not sure how easy the tool support would be. If the shadow
> vocabulary isn't part of the rdf->owl mapping (which it wouldn't be until
> future OWL versions) then it's only visible to me as a collection of
> individuals and object property assertions.

Tool support would be essential - we would need to extend OWLAPI and
Protege's support and I'd have to add support in LSW. There would be
no individuals or object property assertions - everything would be
annotations between annotation IRIs. Otherwise it's not much help,
IMO.

> I have to know the fairly
> complex details of how the axioms map to rdf in order to work with them -
> and if the deprecated axioms themselves have annotations (which they do in
> my case) then we're left with a fairly complex graph of objects whose high
> level structure is largely opaque. One of the nice things about working with
> high level APIs like the OWL API is that I'm freed from worrying about the
> underlying rdf complexity.

Of course. As I said, needs tool support - not a trivial fix. OTOH,
possibly a lasting one.

> what do you think of the alternative, of just adding an owl:deprecated
> annotation, and then shunting the axiom off to the side in a shadow
> ontology, that is typically not imported?

Certainly works (for the cases we care about)
I don't think you could ever import it in a reasoned-over context.
It's not clear then, that the deprecation axiom does anything, if you
are already marking them by isolating them in a different file.
This wouldn't work for deprecated annotation axiom on an axiom, since
you can't maintain the link across files.
-Alan

>
> -Alan
>
> If we did that then we could just translate the axioms into
>
>
>>
>>
>> Is there any recommended practice here?
>
>
>
Received on Thursday, 8 December 2011 17:03:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 January 2012 18:13:41 GMT