- From: Bijan Parsia <bparsia@cs.man.ac.uk>
- Date: Sun, 25 Nov 2007 15:40:06 +0000
- To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>
- Cc: public-owl-wg@w3.org
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