Re: Fwd: Re: Comment on non-global keys

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