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 10:24:53 +0000
Message-Id: <FA38BCF4-E0CA-4E74-80A2-C9C611D95D3C@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 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:
>>> 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:
>> One checks with the associated spec.
> Where?  Who determines?  How specified?

Hmm. These don't seem to be serious questions.

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.

How do you know what the correct processing of an OWL document is?  
Who determines? How specified?

>>>   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.
> Suppose I claim that you are pointing to the wrong thing?

I hereby claim that my understanding of what a sequence of letters  
means is *constitutive* of its meaning. I understand the sequence,  
when entered by you in an email message as above, "Suppose I claim  
that you are pointing to the wrong thing?" means "Bijan, I  
wholeheartedly support your proposal in every detail. Good show."

What's the difference? Nothing. There's no enforcement mechanism for  
*any* of our specs other than social convention, moral suasion, and  
market forces. Again, I'm no worse off and I fail to see that you are  
any better off. Suppose I claim my tool understands all syntactic  
extensions. How could you refute my claim?

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

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

>> 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.
> As I said before, perhaps not a major change to implementations  
> (but I'm
> not convinced on the point), but a major change in philosophy.

Not really, or only to your idiosyncratic (though perhaps shared)  
philosophy. In which case, I don't think it's a powerful point. In  
fact, it seems to me to be little more than an expression of  
distaste. That's legitimate, of course, but hardly substantive or  

My proposal provides a bit of support for some existing practices  
which are not going away and which are made less bad by this proposal.

>> [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.
> Nope.  That is just the way things are right now.

Not in my experience.

>>> [...]
>>>> 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.
> Yes please, I need pointers and details.

I need specifics as to where you think the examples I've already  
given are deficient in supplying your needs. After all, there *are*  
pointers in:

Perhaps you could work through how one of them would work and I could  
check to see if our understandings aligned.

Received on Monday, 26 November 2007 10:24:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:00 UTC