Re: Rich Annotations

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

> 
> On Nov 25, 2007, at 11:12 AM, Peter F. Patel-Schneider wrote:
> 
> > 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:

[...]

> >>> (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?
> 
> Yes. Though I will point out that Googling works here.
> 	http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383500
> 	http://www.w3.org/TR/xmlschema-1/#declare-openness
> 
> (The latter is somewhat confusing, but see 3.10.4.)

The SOAP mechanism appears to be allowing syntax extensions (new header
blocks) that can be tagged with a "mustUnderstand" flag.  I view this as
very different from, and much more palatable than, the ability to change
the meaning of existing syntax.  (By the way, the SOAP 1.2 documents,
e.g., http://www.w3.org/TR/2007/REC-soap12-part0-20070427/, appear to be
more understandable than the one you pointed to.)

The XML Schema mechanism appears to be a way of turning off or on some
extra syntax processing.  I find it more than somewhat confusing.
However, again, I don't find it a way of arbitrarily modifying the
semantics of a construct.

> >>>> 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?
> 
> If you are using those other extensions that you aren't using the  
> *certain sorts of extension* in question. I'm certainly not the only  
> person who has used these sort of extension.

Sure, but I still don't see why the OWL recommendation should cater to
non-conforming uses of the OWL constructs.

> > 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.
> 
> This proposal prevents that from being inadvertent.

How?  People can still do whatever they want.  They can still use the
OWL syntax in non-conforming ways without using a flagging mechanism.

> >> 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.
> 
> Yeah. Your tactics don't actually reduce the number of extensions,  
> because people will and do extend. And they *will* use paths of less  
> resistance. Thus, I'd rather make those paths somewhat more robust.

I view having a syntax extension as more robust.  I view a modification
of the meaning of existing syntax as the least robust kind of change to
a specification, no matter how it is signalled.

> >>>   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?
> 
> As annotations.  

Huh.  You mean view a probablistic subclass as an annotation?  This
seems wrong.  

> Thus I can view and edit them. It can easily "red"  
> or otherwise highlight that there are such annotations. Plus, in the  
> same way that Swoop lets you browse all the disjointness axioms, it  
> can display the list of mustUnderstand annotations upfront.

But how will this help in understanding the modified OWL syntax?   

> > 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).
> 
> But I have a fighting chance of figuring out what's going on.

How?  If the annotation semantics says that subClass axioms now mean
disjointness, that conjunction is implication, and complement is
idempotent, then a lot of what the tool presents will be misleading.

> >>> 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 though 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).
> 
> If you want to champion in the community syntactic extensions, go  
> ahead. But this proposal is trying to deal with same-syntax semantic  
> extensions/variation which is fairly common. I don't particularly  
> *like* it, but I'd rather have some ways of handling it better.

Well, then we differ.  I don't think that it is the WG's business to
provide help for unsanctioned uses of the recommendation.  Even if it
was, then I think that there are much better ways for providing
extensions (such as a way of providing syntax extensions within the
recommendation).

> >> 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.
> 
> Which is often encoded *in OWL*. See SWRL.

You mean http://www.w3.org/Submission/SWRL/?  Where is the encoding in
OWL?

[...]

> > 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.
> 
> That is indeed part of the point of the proposal. So I'm glad we're  
> in agreement that far.
> 
> Cheers,
> Bijan.

Yes, I agree that some parts of the proposal are good.  It is just the
ability to change the semantics of OWL constructs that I find bad.

Peter F. Patel-Schneider
Bell Labs Research

Received on Sunday, 25 November 2007 13:19:40 UTC