Re: Rich Annotations

On Nov 25, 2007, at 3:09 PM, Peter F. Patel-Schneider wrote:

> From: Bijan Parsia <bparsia@cs.man.ac.uk>
> Subject: Re: Rich Annotations
> Date: Sun, 25 Nov 2007 13:48:08 +0000
>
>> On Nov 25, 2007, at 1:04 PM, Peter F. Patel-Schneider wrote:
>>
>>> From: Bijan Parsia <bparsia@cs.man.ac.uk>
>>> Date: Sun, 25 Nov 2007 11:52:40 +0000
[snip]
>> 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.
>
> What processing model?  Does your proposal provide a way of  
> determining
> when a tool does the right thing for (i.e., understand) these  
> annotated
> constructs?

One checks with the associated spec.

>   If not, then how can one determine conformance?

By checking with the associated spec.

> I could
> cliam that my tool understands all annotations; how could you  
> refute my
> claim?

By pointing to the associated 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.

> [...]
>
>>>> 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.
>
> OK.  I suppose that one could think of the status of annotation spaces
> as a modifier on the syntax of existing OWL syntactic constructs.
> However, I don't view this as a desirable syntax extension mechanism.

Fine.

> In any case, I would count it as a major change to OWL.

Why? It's a small change to any tool (detect mustUnderstand, punt if  
tool isn't aware of the extension). This is exactly the current  
status except one is not required to punt.

[snip]
>> 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.
>
> I, on the other hand, would like to make it very clear in the
> recommendation that these sorts of uses of annotations are not
> conformant to the specification.

And that is a departure from OWL as she are practiced. Which, I would  
argue, is a bigger departure.

> [...]
>
>> 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.
>
> It would be useful to have some examples of how these sorts of things
> would work.

I listed examples. If you would like more detail, feel free to ask on  
any of them. Pronto is described in a series of blog posts.

>> As do
>> arbitrary abox statements which encode syntax of something else
>> (because at least now I can *tell* that they are semantically
>> significant).
>
> Well, perhaps.  However, it might be the case that reasoning is needed
> to determine which ABox statements have extra semantics.

So? I would advocate a "Stop the world" model if there are *any*  
mustUnderstand annotations. If one wants more fine grained control  
the proposal becomes more complex. The associated spec would  
determine how the extension works.

[snip]

> Ah, you mean the encoding of SWRL rules into RDF triples (and thus  
> into
> OWL facts).  I was looking for something that used things like  
> subClass
> axioms.

Ah. Yeah, the proposal isn't limited to annotations on TBox axioms,  
of course. Arguably, ABox statements as extra syntax are more common.  
But I don't see a great way to rule in one and rule out the other  
except on a case by case basis. For example, it seems nuts to make  
tbox axioms under constraint semantics have a radically different  
encoding as triples. Similarly for conditional constraints. For rules  
things are rather different.

> This seems like a very different sort of extension (but one that I  
> don't
> like either, by the way).  Are you proposing that both of these  
> sorts of
> extensions be handled using your annotation mechanisms?

Yep. You'd mark these facts with annotations indicate that they are  
part of a rule and are mustUnderstand.

Cheers,
Bijan.

Received on Sunday, 25 November 2007 15:51:26 UTC