- From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
- Date: Sun, 25 Nov 2007 08:04:01 -0500 (EST)
- To: bparsia@cs.man.ac.uk
- Cc: public-owl-wg@w3.org
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 > > > >> > >> On Nov 25, 2007, at 9:51 AM, Peter F. Patel-Schneider wrote: [...] > >>> (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 SOAP mechanism appears to be allowing syntax extensions (new header blocks) 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. (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. I find it more than somewhat confusing. However, again, I don't find it a way of arbitrarily modifying the semantics of a construct. > >>>> 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, but I still don't see why the OWL recommendation should cater to non-conforming uses of the OWL constructs. > > 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. > >> 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. 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. > >>> 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. > 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? > > 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. > >>> 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 though 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. Well, then we differ. I don't think that it is the WG's business to provide help for unsanctioned uses of the recommendation. 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). > >> 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? [...] > > 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. Yes, I agree that some parts of the proposal are good. It is just the ability to change the semantics of OWL constructs that I find bad. Peter F. Patel-Schneider Bell Labs Research
Received on Sunday, 25 November 2007 13:19:40 UTC