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

Re: Rich Annotations

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Mon, 26 Nov 2007 14:50:52 +0000
Message-Id: <97D8B6E1-0C40-4304-99B3-3DED64D881A5@cs.man.ac.uk>
Cc: public-owl-wg@w3.org
To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>

On 26 Nov 2007, at 13:59, Peter F. Patel-Schneider wrote:

> 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:
> I have no problem with others creating extensions to OWL, as long  
> as the
> extension doesn't mess OWL itself

What do you mean by "mess"? Always a monotonic extension? The models  
are conservative extensions?

> and the extension can be recognized.

Every extension to OWL changes it. The thing I'm arguing for allows  
us to recognize extensions.

> However, yes, indeed, I am arguing against the OWL spec providing  
> hooks
> for extensions, particularly ones that change the meaning of OWL
> constructs.

What counts as not changing the meaning?

> 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.

It provides for recognition. Right now, if some one loads a file with  
RDF encoded swrl rules into fact++, fact++ must recognize the swrl  
terms and idioms as such and reject them. And explain to the user why  
it is doing so. I think it's preferable to make all that more  
transparent to the end user and easier on the tools.

Whether it is overall more desirable than possible alternatives is  
one issue. That it's a relatively minor extension seems indisputable.  
You may find it worrisome because it makes less painful (in some  
sense) a practice you deplore. But presumably you deplore it because  
of the pain.

>> [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.

You don't have to. Pick another like constraints.

> 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
> http://www.ece.uc.edu/~klinovp/pronto/cancer/cancer_ra.owl.

You seem to be conflating the evaluation of particular extensions  
with evaluating the extensibility mechanism.

> [...]
>>>> 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>?

That's not an annotation property. Per the grammar fragment, its is a  
space URI.

> What is the role of the annotation value <http://ex.org/ 
> Pronto#certainty>?

Please examine the grammar fragments in the proposal. If they are  
unclear I'd like to repair them. This is an annotation URI/property.

> What is the role of 0;0.132?

It is the value of the annotation property.

> How do they connect to the Pronto extension
> to OWL?

Under the Pronto extension subclass axioms with certainty annotations  
are interpreted as conditional constraints.

> Are there syntactic restrictions on the annotations?

Sure. p:certainty is the only property. You have at least one (to be  
a conditonal constraint) but can have many.

>> 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?

This is something we should decide. I would say the space.

>> 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?

Pronto is new, so it's not too surprising. But presumably if someone  
uses the extension they are aware of it and can get to the spec. You,  
qua implementor, will only get a complaint if you encounter a file  
using the extension. Googling "pronto pellet" or "pronto owl" both  
return reasonable results. Plus you could ask on public-owl-dev and  
like fora.

Worst case, you reject the file. Uhm. Which you would do with a  
syntactic extension.

>> 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.

It's worse without any indicators that's its an extension.

>> 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.

I agree that would be nice, but, uhm, so? When shall this happen? I'm  
not saying mustUnderstand annotation spaces are brilliant or the best  
way forward overall, just that they help with the situation for a  
reasonable chunk of the future.

>   Proposals that provide band-aids for broken
> solutions are not advances, in my view.

Maybe, but they also aren't a large change, nor do they break things  

I live with legacy systems and techniques. This would make things  
somewhat better for me. I fail to see that they would hurt you, so  
it's pretty much a pareto improvement (pace your feelings of disgust).

Received on Monday, 26 November 2007 14:49:40 UTC

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