Re: Rich Annotations

On Nov 25, 2007, at 9:51 AM, Peter F. Patel-Schneider wrote:
[snip]
>> The qualms are:
>> 	1) This is a big change (too big for an OWL 1.1 change)
>> 	2) This is hard to deal with in OWL Full
>
> I agree with Jeremy that the overall proposal is quite a major change,
> in the basic way OWL works, if not in changes required for tools.

Though, I take it, specifically with the "mustUnderstand" bit.

[snip]
>> 	3) mustUnderstand (this *is*, perhaps, a major extension, but an
>> extra logical one; it's a very standard bit of webbiness! it's a hook
>> that allows for extensibility).
>
> I view this as a major change.  Through this part of the proposal one
> could change the meaning of just about any part of the OWL syntax.

People do this already. This just allows them to mark it.

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

> (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").

>> 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. It allows for semantic extensions without  
having to entirely revise the grammar and editors, etc.

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

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

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.

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

Cheers,
Bijan.

Received on Sunday, 25 November 2007 10:29:56 UTC