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: Mon, 26 Nov 2007 08:59:46 -0500 (EST)
Message-Id: <20071126.085946.82231493.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: Mon, 26 Nov 2007 13:32:27 +0000

> On 26 Nov 2007, at 11:19, Peter F. Patel-Schneider wrote:
> > From: Bijan Parsia <bparsia@cs.man.ac.uk>
> > Subject: Re: Rich Annotations
> > Date: Mon, 26 Nov 2007 10:24:53 +0000
> >
> >> On 26 Nov 2007, at 09:13, Peter F. Patel-Schneider wrote:
> >>
> >>>
> >>> From: Bijan Parsia <bparsia@cs.man.ac.uk>
> >>> Subject: Re: Rich Annotations
> >>> Date: Sun, 25 Nov 2007 15:40:06 +0000


> >>>> It isn't magic, just a hook. This is no different than the current
> >>>> situation *except* I have a way of indicating to arbitrary tools  
> >>>> that
> >>>> I've included an extension. That's all this is doing.
> >>>
> >>> Yes, this may be *all*, but it seems to me to be a very big all.
> >>
> >> Yeah, and I have no idea why.
> >
> > Because it pushes parts of the OWL specification into other places.
> No. It pushes specification of *extensions* to OWL to other places.  
> Which is already the case and would be, I imagine, true of *any*  
> extensibility mechanism. Before you were arguing against some details  
> of *this* proposal (and in favor of a somewhat different  
> extensibility mechanism). Now you seem to be arguing against  
> extensibility at all (at least extensibility used by people outside  
> the W3C).

I have no problem with others creating extensions to OWL, as long as the
extension doesn't mess OWL itself and the extension can be recognized.
However, yes, indeed, I am arguing against the OWL spec providing hooks
for extensions, particularly ones that change the meaning of OWL

I do realize that many extensions don't meet the second requirement
above.  I view this as deplorable, but I don't see the proposal as
providing a good way to ameliorate the problem.

> [snip]
> >>  After all, there *are*
> >> pointers in:
> >> 	http://www.w3.org/2007/OWL/wiki/Annotation_System#Examples
> >
> > What I see there are three examples of extensions to OWL.  For
> > constraints and OntoClean, I don't see a worked-out solution as to how
> > the annotation proposal would support the extension.  For Pronto, I  
> > see
> > annotations, but no annotation spaces.
> Because when we did Pronto, the proposal wasn't on the table.
> Really, is it that hard to see how it would go? See below.

Yes, for me it is hard to see how it would go.  I couldn't (easily) find
a manual for Pronto.  I looked at Probabilistic Description Logics
for the Semantic Web by Thomas Lukasiewicz, and quickly ran into
problems, starting with how to write arbitrary real numbers in OWL.  I
also didn't see a close correspondence between the language there and
the example Pronto ontology at


> >> Perhaps you could work through how one of them would work and I could
> >> check to see if our understandings aligned.
> >
> > No thanks.
> Why not? I'm really at a loss as to which parts are puzzling you.  
> Wouldn't it be a better test of the design if you tried it?
> > How about you work through how one of them would work and I could  
> > see if
> > I can understand more?
> Here's a sketch.
> Ontology(<http://ex.org/#testOnt>
> 	AnnotationSpace(<http://ex.org/Pronto> mustUnderstand)
> 	SubClassOf( Annotation(<http://ex.org/Pronto> <http://ex.org/ 
> Pronto#certainty> 0;0.132) Woman, WomanWithBRCInLongTerm)
> )

What is the role of the annotation property <http://ex.org/Pronto>?
What is the role of the annotation value <http://ex.org/Pronto#certainty>?
What is the role of 0;0.132? How do they connect to the Pronto extension
to OWL?  Are there syntactic restrictions on the annotations?

> There is a bit of ambiguity in the space uri (i.e., does it identify  
> the particular space token or the space type), but that's easily  
> decided one way or the other.
> If a reasoner gets this and it doesn't have this space in its  
> internal list of understood annotations then it should punt on the  
> file ("Can't reason with this file because I don't understand <http:// 
> ex.org/Pronto> annotations; 

The annotation space or the annotation property?

> I could reason with this file while  
> ignoring those annotations but the results may not be as the ontology  
> author intended.")
> In order to (correctly) reason with documents with these annotations,  
> the tool must conform to the relevant spec. I do not propose that  
> such specs be necessarily accessible via the annotation space URI or  
> anything like that (though one could do and I imagine many people  
> will). I just publish my spec. Usually a googling will suffice to  
> find it.

You mean the document at http://www.pronto.philips.com/, which is the
current first Google hit for Pronto?

> This is very much how SWRL, for example, currently works except there  
> is no hint to vanilla OWL reasoners that SWRL rules encoded as RDF  
> statements have significant extra-OWL/RDF semantics. In fact, there  
> is no *way* to so hint. 

Oh, I very much agree that the encoding of SWRL rules as RDF triples is
a bad idea.   

> This is a way to so hint. It doesn't stop  
> someone from claiming that their ad hoc rule engine (or dl safe rule  
> engine) correctly implements the SWRL spec. But so? It gives a  
> standard way for an OWL tool to tell the user that it is, for all  
> that it knows, not respecting the semantics of the extension. If the  
> author doesn't put in the mustUnderstand, then, too, the mechanism  
> won't work.

My view is that the way ahead is to have a real rule extension to OWL
(probably not SWRL), with its own syntactic constructs, as is done in
the SWRL abstract syntax.  Proposals that provide band-aids for broken
solutions are not advances, in my view.

> Cheers,
> Bijan.

Peter F. Patel-Schneider
Bell Labs Research
Received on Monday, 26 November 2007 14:18:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:00 UTC