W3C home > Mailing lists > Public > public-owl-wg@w3.org > November 2007

Re: Rich Annotations

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Sun, 25 Nov 2007 10:09:54 -0500 (EST)
Message-Id: <20071125.100954.107784893.pfps@research.bell-labs.com>
To: bparsia@cs.man.ac.uk
Cc: public-owl-wg@w3.org

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

> On Nov 25, 2007, at 1:04 PM, Peter F. Patel-Schneider wrote:
> 
> > From: Bijan Parsia <bparsia@cs.man.ac.uk>
> > 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>
> >>> Date: Sun, 25 Nov 2007 10:29:52 +0000

[...]

> >> 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.
> 
> This makes it conforming and specifies a processing model. I don't  
> see how you can appeal to the bad of sanctioning non-conformingness  
> if the proposal makes it conforming. You may not want such uses to  
> conform, but that's different.

What processing model?  Does your proposal provide a way of determining
when a tool does the right thing for (i.e., understand) these annotated
constructs?  If not, then how can one determine conformance?  I could
cliam that my tool understands all annotations; how could you refute my
claim?

[...]

> >> 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.
> 
> The syntax would be e.g., "SubClassOf with a mustUnderstand  
> annotation". I'm proposing that this be a kind of syntactic extension.

OK.  I suppose that one could think of the status of annotation spaces
as a modifier on the syntax of existing OWL syntactic constructs.
However, I don't view this as a desirable syntax extension mechanism.

In any case, I would count it as a major change to OWL.

> >>>>>   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.
> 
> No, I view subClassOf syntax with annotations marking them as  
> conditional constraints as a way of extending syntax.
> 
> (Besides, consider annotated logic :))
> 
> I think you have a preference for things called "annotations" to be  
> "semantically meaningless". I just view them as a syntactic category.  
> People will write tools that are sensitive to that syntactic  
> category. Some of these might involve overriding (in a *variety* of  
> ways) the default interpretation of other bits of syntax. When that  
> happens, I'd like to mark it.

I, on the other hand, would like to make it very clear in the
recommendation that these sorts of uses of annotations are not
conformant to the specification.

[...]

> Right but I can at least see which subClass axioms are disjointess  
> axioms, etc. Again, if my extension is radically non local, that will  
> be of limited use, but you are just pointing out a limitation. Yeah,  
> it has limits. So? Constraints, non-mon inheritence, probabilities,  
> axiom schemas, etc. all seem to work fairly reasonably. 

It would be useful to have some examples of how these sorts of things
would work.

> As do  
> arbitrary abox statements which encode syntax of something else  
> (because at least now I can *tell* that they are semantically  
> significant).

Well, perhaps.  However, it might be the case that reasoning is needed
to determine which ABox statements have extra semantics.

[...]

> >>>> 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?
> [snip]
> 
> http://www.w3.org/Submission/SWRL/#6

Ah, you mean the encoding of SWRL rules into RDF triples (and thus into
OWL facts).  I was looking for something that used things like subClass
axioms.

This seems like a very different sort of extension (but one that I don't
like either, by the way).  Are you proposing that both of these sorts of
extensions be handled using your annotation mechanisms?

> Cheers,
> Bijan.

Peter F. Patel-Schneider
Bell Labs Research
Received on Sunday, 25 November 2007 15:26:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:13:27 GMT