Re: Rich Annotations

On Nov 25, 2007, at 1:04 PM, Peter F. Patel-Schneider wrote:

> From: Bijan Parsia <bparsia@cs.man.ac.uk>
> Subject: Re: Rich Annotations
> Date: Sun, 25 Nov 2007 11:52:40 +0000
>
>>
>> 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
[snip]
>> 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 SOAP mechanism appears to be allowing syntax extensions (new  
> header
> blocks)

? The header syntax is the same.

> that can be tagged with a "mustUnderstand" flag.  I view this as
> very different from, and much more palatable than, the ability to  
> change
> the meaning of existing syntax.

I see. You're hung up on the change of existing syntax. Meh. If I  
have an annotation then the subClass axioms are syntactically  
distinguishable from one's without those annotations.

> (By the way, the SOAP 1.2 documents,
> e.g., http://www.w3.org/TR/2007/REC-soap12-part0-20070427/, appear  
> to be
> more understandable than the one you pointed to.)
>
> The XML Schema mechanism appears to be a way of turning off or on some
> extra syntax processing.

Strict processing requires that I validate the element. Lax allows me  
to skip it. This is a mustUnderstand/mayIgnore situation.

>   I find it more than somewhat confusing.
> However, again, I don't find it a way of arbitrarily modifying the
> semantics of a construct.

It's mustUnderstand vs. mayIgnore extensibility.

[snip]
>> 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, but I still don't see why the OWL recommendation should cater to
> non-conforming uses of the OWL constructs.

This makes it conforming and specifies a processing model. I don't  
see how you can appeal to the bad of sanctioning non-conformingness  
if the proposal makes it conforming. You may not want such uses to  
conform, but that's different.

>>> 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.
>
> How?  People can still do whatever they want.  They can still use the
> OWL syntax in non-conforming ways without using a flagging mechanism.

Sure. But I would argue that they'd be less likely to. And that  
that's a good thing.

I can agree that best practice would  be a total syntactic extension.  
I think, however, that that is not particularly common and has some  
serious deployment downsides.

But anyway, using annotations as a syntactic extensibility mechanism  
allows me to extend syntax. If you want to extend syntax in a  
different way, propose a mechanism. This one works across different  
serializations.

[snip]
>> 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.
>
> I view having a syntax extension as more robust.  I view a  
> modification
> of the meaning of existing syntax as the least robust kind of  
> change to
> a specification, no matter how it is signalled.

The syntax would be e.g., "SubClassOf with a mustUnderstand  
annotation". I'm proposing that this be a kind of syntactic extension.

>>>>>   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.
>
> Huh.  You mean view a probablistic subclass as an annotation?  This
> seems wrong.

No, I view subClassOf syntax with annotations marking them as  
conditional constraints as a way of extending syntax.

(Besides, consider annotated logic :))

I think you have a preference for things called "annotations" to be  
"semantically meaningless". I just view them as a syntactic category.  
People will write tools that are sensitive to that syntactic  
category. Some of these might involve overriding (in a *variety* of  
ways) the default interpretation of other bits of syntax. When that  
happens, I'd like to mark it.

>> 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.
>
> But how will this help in understanding the modified OWL syntax?

It doesn't. You have to look up the associated spec. But in a lot of  
cases it allows me to *function* in existing tools with a syntactic  
extension. If the spec says, "This extension screws up the class  
hierarchy entirely, not just locall" then, yeah, I could be misled.  
That would be an extreme case, of course. It's not a panacea, it's  
just a hook.

>>> 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.
>
> How?  If the annotation semantics says that subClass axioms now mean
> disjointness, that conjunction is implication, and complement is
> idempotent, then a lot of what the tool presents will be misleading.

Right but I can at least see which subClass axioms are disjointess  
axioms, etc. Again, if my extension is radically non local, that will  
be of limited use, but you are just pointing out a limitation. Yeah,  
it has limits. So? Constraints, non-mon inheritence, probabilities,  
axiom schemas, etc. all seem to work fairly reasonably. As do  
arbitrary abox statements which encode syntax of something else  
(because at least now I can *tell* that they are semantically  
significant).

[snip]
>> 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.
>
> Well, then we differ.  I don't think that it is the WG's business to
> provide help for unsanctioned uses of the recommendation.

I'm proposing sanctioning it. So it wouldn't be unsanctioned. So,  
uhm, this argument doesn't work. QCRs aren't sanctioned by OWL 1.0,  
but we're proposing sanctioning it in NextOWL.

You can argue that we shouldn't sanction it, but this particular line  
is just incoherent. I'm proposing to sanction a certain extensibility  
mechanism.

I guess you mean that you don't like overloading extant syntax. Fair  
enough (though, it doesn't *quite* propose that, the way, for  
example, having a global flag that made all subClass axioms into  
disjoint axioms would; of course, there's no effect constraint we can  
put on an extension, but this is always true).

> Even if it
> was, then I think that there are much better ways for providing
> extensions (such as a way of providing syntax extensions within the
> recommendation).

Propose away. It'll be unsanctioned :)

>>>> 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.
>
> You mean http://www.w3.org/Submission/SWRL/?  Where is the encoding in
> OWL?
[snip]

http://www.w3.org/Submission/SWRL/#6

Cheers,
Bijan.

Received on Sunday, 25 November 2007 13:48:10 UTC