- From: Holger Knublauch <holger@knublauch.com>
- Date: Mon, 05 Dec 2005 13:49:12 +0000
- To: swbp <public-swbp-wg@w3.org>
Thanks greatly for your comments, Elisa! My comments are inline. Holger Elisa F. Kendall wrote: > > Hi All, > > I've reviewed the 2005/11/14 version of the note posted at > http://www.w3.org/2001/sw/BestPractices/SE/ODSD/ > and have the following comments: > > Overall, this looks pretty good from my perspective, and the examples in > particular are really helpful. > > 1. Abstract -- I think Jeremy had feedback on this - it really needs > tightening up and possibly bullets would > help with the flow. If Jeff/Phil would like me to help in this regard, > let me know once the other issues > have been addressed. We will post a revised version of the abstract in the next public version over the next few days. We also need to incorporate recent comments from Grady Booch. > 2. Introduction -- I would like to see the example use OCL to represent > the constraint that is currently a > note, since MDA-based models that adhere to design by contract methods > would do this today, enabling > code generation for the behavioral constraint as well as for the > structural elements of the model. There may > be a similar example in Dave Frankel's book we can draw from to support > this, for a similar application, > in fact. Also, several of the issues raised in the paragraph beginning > "Since we anticipate ..." could actually > be handled today through OCL - we should find specific semantic issues > that either cannot be, or that are > really tricky to implement in OCL rather than the simpler ones, or use > the countries example from the > following paragraph to show how the semantics differ. The comparison between OCL and OWL is a recurring topic, very worth discussing. I am not an OCL expert and hope that someone else can correct me. My belief is that OCL has been created to define constraints to limit class membership to those instances that fulfill these constraints. This is useful in many real-world settings, especially to provide a formal documentation of the anticipated use cases of a (UML) diagram. OWL restrictions can play a similar role (if the developers decide to interpret restrictions in a rather closed world sense), but the focus is on supporting reasoning. A key concept here is the distinction between defined and primitive classes. This distinction is not obvious in OCL, making automated reasoning difficult. I am also not sure about how many "real" programmers use OCL nowadays. My personal opinion is that there is more being written about it than people really use it. The goal of this paper is to attract mainstream developers to look into Semantic Web technology. I have tried to make the paper as simple as possible, so that the target audience finds a common grounding where it can hook into and understand the topic, without being put off by yet another formal language. Furthermore, I don't want to argue that one language is more expressive than the other - I am sure there are work-arounds where both can cover a lot of ground. However, one of the main messages of the paper is to stress the advantage of *model sharing on the Web*. OCL is not a Web language, and OO models are developed for a closed world, usually limited to a certain application or enterprise. So I don't think it is necessary or helpful for the understanding of the introduction to include OCL in the first Figure. However, you are absolutely right that OCL should not go unmentioned. I suggest the following additional paragraph to the end of the Introduction: "To summarize, the key benefits of RDF Schema and OWL compared to object-oriented languages are: Reuse and interoperability: RDF and OWL models can be shared among applications and on the web Flexibility: RDF and OWL models can operate in an open environment in which classes can be defined dynamically etc Consistency and Quality Checking across models Reasoning: OWL has rich expressivity supported by automated reasoning tools [begin] Note that some of these benefits such as consistency checking and automated reasoning can also be achieved by means of the Object Constraint Language (OCL). OCL is part of the OMG's family of languages for Model-Driven Architecture, and provides similar expressivity like modern Semantic Web languages. For example the constraint from Figure 1 could have been expressed in OCL to formalize the conditions of duty-free orders. However, OCL has not been designed for the Web, but is optimized to represent constraints within rather closed data models. Semantic Web technology has been designed for an open world, in which models are shared among multiple applications and groups. We will show later how this openness manifests itself in the Semantic Web languages. It is worth noting though that the differences between object-oriented languages and OWL are not impossible to bridge. In fact, an OMG working group is defining an Ontology Definition Metamodel <a href="#ref-ODM-2005">[ODM 2005]</a> that will allow developers to use Semantic Web languages in tandem with other formats such as OCL.[end] This document now goes on to explain how object-oriented applications can be designed and implemented with the help of Semantic Web technologies..." > One thing that could be emphasized is the advantage that separating the > domain vocabulary from the > rules (OCL) brings not only from a reusability/patterns perspective but > from a scalability perspective when > talking about design-by-contract. Factoring the vocabulary from the > rules not only addes this, but > supports reuse of rule patterns. Maybe I don't understand this aspect. From any OCL-embellished UML diagram you can always still extract the classes tree, and only reuse parts of it. Could you clarify where in the paper I could reflect your comment? Thanks. > 3/4. Application Development -- Either here or in the following section, > it would be good to have a paragraph > to discuss a stepwise process that includes ontology development, > consistency checking, validation --> > integrating the ontology with the application --> consistency checking > of parts of the application model > where possible using OWL reasoners --> code generation. This might fit > in with the Dynamic > Object Model discussion, but the advantages of model consistency > checking cannot be emphasized enough > here. I agree this would be nice to have. I am not sure though how to fit it into the flow of the document, without expanding the paper (and pushing back the projected publication date which we all hope to reach before x-mas). We did not cover the development process issues with ontologies at all, and I feel this may go beyond the scope of this paper. It would be great to have a reference to a paper on this so that we can link to other work. If there are no other papers on this topic, then a Best Practices note is not the best place to invent the theory. I suggest if anyone else wants to contribute a paragraph or two, we could integrate them. > Appendix -- no mention of ODM? or any of the OMG standards? I'll > create a list of links and references > to add and forward them to SE separately, along with inline comments on > the document itself. As you have seen, I am suggestion to add this as a reference with an inline comment in the introduction. Let me know if you are not happy with this :)
Received on Monday, 5 December 2005 13:49:27 UTC