- From: <ewallace@cme.nist.gov>
- Date: Wed, 7 May 2003 16:39:57 -0400 (EDT)
- To: www-webont-wg@w3.org
Jim Hendler forwarded: >From: Dan Connolly <connolly@w3.org> ... > >Comments of the form "your design doesn't let me do X" fit >best into the WG process as "please add X to your requirements". > >With a bit of a stretch, compound keys can be connected >to objective 015. Complex data types >http://www.w3.org/TR/webont-req/#obj-complex-data-types > >so I think this shows that the WG has considered this requirements >and not accepted it. > >Or is that too much of a stretch? > >I don't see much in the way of new information, so I think the >chairs should decide that this doesn't merit re-opening that decision. > >Moreover, in the status section, we see: > >"Requests for significant changes to the requirements are not >anticipated and will be evaluated in the context of the scope and >schedule of the Web Ontology Working Group charter and other plans for >the W3C Semantic Web Activity (Activity Statement)." > -- http://www.w3.org/TR/webont-req/ > I would say that it is a stretch to assert that the disposition of the complex data types feature as an objective shows wg consideration of a "compound key" feature. The complex data types feature could easily be used to express compound keys with DatatypeProperties, but was that the reason that the feature was requested? More importantly, was there something about that particular usage of complex data types that caused it to be categorized as an objective rather than a requirement or were there other issues such as those that have come up for user defined data types. A compound key feature is a special case of the joint uniqueness constraint available in some data modeling languages. In NIAM/ORM this can be applied to its equivalent of ObjectProperties just as easily as its equivalent of DatatypeProperties. An example, not terribly far removed from our requirements uses cases (Design documentation in particular), would be identifying the process plan (i.e. manufacturing recipe) for the Product to be produced on the 3rd line of the Flint, Michigan plant during the PM shift in a particular automaking enterprise. The ability to call out specific versions or variants of a product model based on parameters such as in this example is called "effectivity." It would be reasonable to consider a joint uniqueness feature for some version of OWL, but I could find nothing in the Requirements document that actually calls for this feature. The Product documentation use case doesn't explicitly cover effectivity and no other use case, objective or requirement seems to come close to stating or implying the need for OWL to express joint uniqueness. Given this, it looks like Dan's quote from the status section should be sufficient to justify not putting it in this version of OWL. -Evan
Received on Wednesday, 7 May 2003 16:40:01 UTC