Re: Rich Annotations

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:
[snip]
>> People do this already. This just allows them to mark it.
>
> People can do whatever they want.  However, I view having a
> recommendation provide support for the extra-recommendation things  
> they
> do do suspect in the best of situations and harmful in most  
> situations.

The goal is to make them less harmful.

>>> I do
>>> not view this as a good thing.  If one wants extensions to OWL,
>>> then why
>>> not build a real extension to OWL?
>>
>> Because such extensions require revving *all* your tools, changing
>> the mime type (perhaps), etc. etc.
>
> Which I view as a good thing, by the way.

We are diametrically opposed on this point. I don't see the value in  
making extensions harder.

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

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

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

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

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

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

> I don't see how annotations on
> existing syntax can provide this sort of capability.

Yeah, so in this case the rules wouldn't be *in* annotations (though  
they could be), but you could use the same idea to mark parts of syntax.

>>>   I think that
>>> it is much better to just come out with syntactic extensions
>>>
>>>> Indeed, annotation spaces can be seen as syntactic sugar for  
>>>> literals
>>>> or other encodings of syntax into owl or of using multiple  
>>>> documents.
>>>> So conceptually (and praxis-wise) there is nothing new except the
>>>> hint to tools that some encoding might be very significant.
>>>
>>> Well, I guess, but, again, I think that the better way to go is to
>>> have
>>> a syntactic extension.
>>
>> I think sugar for annotation spaces (or a canonical way of encoding
>> them) is highly desirable. My point is that mayIgnore spaces are, in
>> fact, sugar for things you can do now (reification or literals or ad
>> hoc encoding or separate documents).
>
> I don't see how annotations provide reification or literals or other
> encodings.  How would this work?

I mean you can encode spaces using literals or reification.

>> Cheers,
>> Bijan.
>
> 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.

Received on Sunday, 25 November 2007 11:52:42 UTC