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 13:32:27 +0000
Message-Id: <3DE2DEEE-C6CA-4619-9F03-149AFB649C9B@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 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
>>>
>>>> On Nov 25, 2007, at 3:09 PM, Peter F. Patel-Schneider wrote:

[snip]
>>> Where?  Who determines?  How specified?
>>
>> Hmm. These don't seem to be serious questions.
>
> Nope, I consider these to be very serious questions.  There has been
> considerable debate over related issues, including the "social  
> meaning"
> debate (see
> http://www.w3.org/2001/sw/meetings/tech-200303/ and
> http://www.xml.com/pub/a/2003/07/23/deviant.html).
>
>> Each space has an associated name (an URI, presumably). In the normal
>> way for *anything*, there may or may not be a specification
>> associated with terms related (in some manner) to that URI. Since
>> this is bog standard across the W3C, I don't feel I need to say
>> anything beyond that. I don't think I'm making anything *more*
>> broken, if you think existing ways are broken.
>
> In my opinion what makes the current situation not completely  
> broken is
> that there is a fairly well defined notion of which organizations  
> are in
> charge of providing the specifications and that only certain kinds of
> organizations (IETF and W3C, mostly) play this role.  Your proposal
> appears to delegate this authority to arbitrary players, who may  
> play by
> rules different from those normally employed in the WWW.

This is already the case.
[snip]
>> In the normal way, by pointing to the relevant associated specs. I
>> could dispute their relevance, or your interpretation of them, or the
>> meaning of "supports".
>
> Without something in the W3C OWL recommendation as to how to get to  
> the
> correct spec, then there is indeed an issue of which spec to use.  I
> don't see anything in the current spec or in your proposal that tells
> how to make this link.

Ok, there's a URI in the space declaration that indicates the  
controlling spec.

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

>   (By the way, how can I find the
> ontology file:/C:/kl/ClarkParsia/Cancer/Ontology/cancer_ra.owl,
> referenced in
> http://www.ece.uc.edu/~klinovp/pronto/cancer/cancer_cc.owl?)

http://www.ece.uc.edu/~klinovp/pronto/cancer/cancer_ra.owl

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

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

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

Cheers,
Bijan.
Received on Monday, 26 November 2007 13:31:17 GMT

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