Re: Rich Annotations Use Cases

Bijan (and Vojtech),

Could you be a bit more specific about the language features you  
would like to see, i.e., what changes would be required to the  
structural syntax and semantics documents?

Ian


On 31 Oct 2007, at 13:01, Bijan Parsia wrote:

>
> 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 Sunday, 4 November 2007 19:38:30 UTC