Re: Rich Annotations

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Subject: Re: Rich Annotations
Date: Sun, 25 Nov 2007 10:29:52 +0000

> 
> On Nov 25, 2007, at 9:51 AM, Peter F. Patel-Schneider wrote:
> [snip]
> >> The qualms are:
> >> 	1) This is a big change (too big for an OWL 1.1 change)
> >> 	2) This is hard to deal with in OWL Full
> >
> > I agree with Jeremy that the overall proposal is quite a major change,
> > in the basic way OWL works, if not in changes required for tools.
> 
> Though, I take it, specifically with the "mustUnderstand" bit.

Yes.

> [snip]
> >> 	3) mustUnderstand (this *is*, perhaps, a major extension, but an
> >> extra logical one; it's a very standard bit of webbiness! it's a hook
> >> that allows for extensibility).
> >
> > I view this as a major change.  Through this part of the proposal one
> > could change the meaning of just about any part of the OWL syntax.
> 
> People do this already. This just allows them to mark it.

People can do whatever they want.  However, I view having a
recommendation provide support for the extra-recommendation things they
do do suspect in the best of situations and harmful in most situations.

> > I do
> > not view this as a good thing.  If one wants extensions to OWL,  
> > then why
> > not build a real extension to OWL?
> 
> Because such extensions require revving *all* your tools, changing  
> the mime type (perhaps), etc. etc.

Which I view as a good thing, by the way.

> > (Are there other web proposals that look like this one, by the way?)
> 
> Yes. See SOAP.
> 
> Arguably, the "processContent" value "strict" (in XML Schema) is a  
> mustUnderstand (as opposed to "lax").

Could you provide a pointer to the relevant documents, please?

> >> The degree of 3 is *very* minimal. It's basically a flag saying "Hey,
> >> the author has done something funky and unless you know what that is
> >> you are at high risk of misrepresenting that intent!!!" Thus, it does
> >> not *need* a semantic treatment. This captures a *fair* bit of
> >> current practice (i.e., where in people extend OWL in a variety of
> >> ways, from e-connections to SWRL), but improves interop.
> >
> > I don't buy this.  How does it improve interoperability?
> 
> It prevents reasoners from silently working with documents that have  
> certain sorts of extension. 

And other reasonable methods of providing extensions (like extending the
syntax) don't?  Sure, there may be OWL content that does not abide by
the recommendation, and thus that conforming tools don't follow the
intent of this content, but there is no way that this sort of lossage
can be prevented.

> It allows for semantic extensions without  
> having to entirely revise the grammar and editors, etc.

Well, small extensions should not require "entire" revisions.  In any
case, I view it as a good thing that extensions require significant
work.  If this was not the case, then there would be too many
extensions.

> >   If a tool sees
> > one of the "mustUnderstand" things, the tool really can't do  
> > anything to
> > the document.
> 
> An *editor* can. A reasoner can't. But that's exactly what's wanted.

I don't buy this, except for very simple editors, which are not very
useful.  Consider, for example, Protege.  How can Protege display OWL
content that has mustUnderstand annotations on it?  The annotations may
completely change the semantics of the OWL, invalidating some things that
Protege does without the help of a reasoner (e.g., displaying the told
hierarchy). 

> > Worse, because the document would be syntactically
> > conforming to the OWL spec, sloppy tool writers and users are  
> > encouraged
> > to use the document anyway, leading to incorrect results.
> 
> This is the situation *now* for *everyone*. That is, even thought I  
> don't *need* to use a full blown syntactic extension, I'm forced to.  
> Now I can't browse my document in protege or OWLSight unless they  
> ignore my extensions (in which case they won't even, in my  
> experience, *display* them).
> 
> With mustUnderstand, it'd be easy to have these tools *show* me the  
> extensions.

You mean by having the tool segregate the extension and not do anything
with it?  Nothing prevents a tool from doing this for a syntactic
extension as well (provided that it is possible to delimit the syntactic
extension, which is very often the case).

> And even if you think it's a bad idea overall, the point is people do  
> it (see swrl or OWL-S). So let's give a very simple tool that would  
> allow *some* principled marking of extensions.

How can SWRL or other rule extensions be handled this way?  A rule
extension adds a new kind of syntax.   I don't see how annotations on
existing syntax can provide this sort of capability.

> >   I think that
> > it is much better to just come out with syntactic extensions
> >
> >> Indeed, annotation spaces can be seen as syntactic sugar for literals
> >> or other encodings of syntax into owl or of using multiple documents.
> >> So conceptually (and praxis-wise) there is nothing new except the
> >> hint to tools that some encoding might be very significant.
> >
> > Well, I guess, but, again, I think that the better way to go is to  
> > have
> > a syntactic extension.
> 
> I think sugar for annotation spaces (or a canonical way of encoding  
> them) is highly desirable. My point is that mayIgnore spaces are, in  
> fact, sugar for things you can do now (reification or literals or ad  
> hoc encoding or separate documents).

I don't see how annotations provide reification or literals or other
encodings.  How would this work?

> Cheers,
> Bijan.

I see annotations as largely a way of adding extra-logical information
to ontlogies (like creation information, etc.).  I think that one of the
problems in OWL 1.0 is that annotations didn't work very well for this
purpose and that the OWL 1.1 treatment of annotations is better.  Some
parts of the rich annotation proposal can be used to make the OWL 1.1
situation even better.  


peter

Received on Sunday, 25 November 2007 11:28:07 UTC