Rich Annotations Use Cases

I'll have a separate post on punning, but now I'll make my brief for  
richer annotations (both syntacticly and semanticly).

Semantically, I prefer the base case for annotations to live in a  
difference space, so that they don't affect the behavior of the  
domain model (except in very specific ways). So OWL Full's conflation  
of annotation property and other properties doesn't help, nor does  
OWL 1.1's punning in fact meet this (though it is closer and I  
originally thought it would). Something *like* punning, i.e., some  
insulation, is needed.

1) Development tool metadata.

Author, modifier, touched, modified, obsoleted, etc. are critical  
features that editors like Protege4 or Swoop need to be able to pop  
into OWL documents at both the entity and axiom level. Indeed,  
Gilberto Fragoso of the National Cancer Institute met with me to  
stress how important good annotation support (in particular, they  
need to be able to stuff multiple annotations per axiom, and the  
annotations need to be structured deeply; i.e., they want to encode  
lots of change and review information both from human users and from  
tools).

(Note, I think this is a pretty standard requirement. However, NCI is  
pretty influential having contributed substantial funding to Protege  
development and, recently, to C&P's explanation and incremental  
reasoning work. The NCI thesaurus is also one of the more well known  
OWL ontologies out there. Furthermore, they just finished a mulit- 
year transition to an entirely OWL based workflow...thus a success  
story for OWL. So, they are a key adopter, IMHO.)

An expanded set of annotation properties including e.g., DC terms  
would be helpful here as well as basic syntax improvements.

2) Deployment tool metadata.

Display class, display property, label, must be filled, may be  
filled, expert term, novice term, definitions, skos relations etc.  
These are meant not necessarily for editors per se, but for, e.g.,  
form generators or navigational displays.

I've needed this for any number of tools (PhotoStuff, JSpace, etc.).  
Alan Rector does all sorts of wacky tricks in his work with Siemans  
to help with form generation. (We could get Alan to present on these  
requirements at the F2F.) A fair bit of nominally OWL Full documents  
get that way because they want to subproperty label, or indicate what  
the range of dc:creators is (not for reasoning; for acquisition).

Often one wants subproperty inheritance here (the classic, dc:  
dumbing down) but it seems just as often one wants a *different*  
semantics (e.g., not necessarily OWA, something more databasey,  
queriy, or logic programmy).  So freedom to vary the "rules of the  
game" in the annotations is helpful.

This is also critical, imho. Making it easier to *deploy* OWL  
effectively (or use OWL to support deployed systems) is a very big deal.

3) Language extensions with "must understand".

In C&P's implementation of probabilisitc extensions to OWL based on  
the P-SHOQ formalism,

	<http://clarkparsia.com/weblog/category/semweb/probabilistic- 
reasoning/>

we used axiom annotations to turn subclass axioms into conditional  
constraints (for example). A system cannot *correctly* ignore those  
annotations, but it was a very convenient way to extend the language  
(although one could argue that it was potentially misleading): We  
didn't have to change any basic parsers or editors; it worked in all  
syntaxes for free, etc.

In general, better support for extensions is helpful.

Not quite a language extension, but I would like to be able to mark  
certain entailments as "unverified", or even just as entailments.  
Thus, if a reasoner times out while checking some subsumption, we  
have some way of indicating that *this* entailment isn't checked,  
while still reporting all the ones we found.

4) Language extensions with "may ignore"

Two use cases thus far: Constraint semantics and OntoClean. Actually,  
with constraints it could be must understand, but the point is I want  
to mark some "normal" axioms as checks, not inference generating. In  
my (unreleased) OntoClean tool, I use annotations on classes to  
attach the metaproperties, then I perform OntoClean checking  
separately from domain reasoning. In Welty's attempt to do this in  
OWL Full, an OntoClean violation would make the whole ontology  
inconsistent, but I don't thing that's useful. I'd rather be able to  
work on the two parts independently, after all, sometimes I get a  
violation because my *modelling was wrong* and sometimes because my  
*OntoClean* was wrong, so being able to work with them in parallel is  
very helpful.

Cheers,
Bijan.

Received on Wednesday, 31 October 2007 13:01:42 UTC