RE: SMIng Requirements: instance identification

["Joel M. Halpern" <joel@longsys.com>]

I find this discussion of removing "keying" confusing.  I suspect that the 
problem is that in the object sense "keying" must not be intended as an 
object property at all.

If B is a subclass of A, that means that one can, for all purposes, treat 
an instance of B as if it were an instance of A.

Supposing that A is tefined to have key A_k, and B is defined to have key 
B_k instead.

"Keying" seems to be intended to define what attributes uniquely identify 
an object.  I.e., a search in a well-formed set of objects for any A with 
A_k = X will return only 1 object.  But, if some of the As in the system 
are actually Bs which are keyed by a different attribute, this property 
simply will not hold.

Am I completely misunderstanding the intent?  To paraphrase Andrea, "what 
works for my superclass does not work for me" seems like a violation of 
what subclassing is supposed to do.

Yours,
Joel M. Halpern

At 04:29 PM 2/28/01 -0800, Jason, Jamie wrote:
>Comments in-line.
>
> > 1. Being able to specify a property as a key (an OID, a
> > string, etc.) is
> > different than specifying a naming hierarchy, or the
> > semantics of "how to"
> > create the key.  The SMIng requirements state that a
> > mechanism should be
> > provided to define a property as a key.  That's it.  This is purely
> > language.  How the key is defined/implemented/... is up to
> > the model.  Also,
> > the section about associations (Section 9) clearly states
> > that the ability
> > to specify "containment for scoping and naming" is needed
> > (first paragraph).
> > Now containment may not be appropriate in all models - but
> > the semantics are
> > needed for a general data modeling language.
>
>I second this.  The requirements simply state (and IMHO should simply state)
>that there needs to be a mechanism provided for keying.  How it is done is
>out of scope of the requirements and is left to the mapping from the
>definition language to the particular implemtation.
>
> > 2. I viewed "un-keying" not as breaking inheritance (since
> > the property is
> > still inherited), but as saying "what works in the superclass
> > as a unique
> > identifier does not work for me."  I would hope that this is
> > not used very
> > often, and expected it to generate some discussion :-).  I
> > would like to get
> > Jamie to provide a use case/example - since this was his section.
>
>When I originally came up with this, I did not have a particular example in
>mind, but I agree with what you have written.
>
>However, here is a contrived, US-centric example (I will offer apologies in
>advance of the example).  Excuse the syntax - it in no way is meant to offer
>a syntax for SMIng-defined language, just as an example.
>
>class US_Citizen
>{
>   key string social_security_number;
>   ...
>}
>
>Here in Oregon, the DMV (department of motor vehicles) uses my driver's
>license number instead of my social security number to uniquely identify me,
>so they could have a class (of course this would require that I be a US
>citizen to have a driver's license in Oregon, but let's not worry about
>that...like I said, the example is contrived):
>
>class Oregon_Driver derives from US_Citizen
>{
>   boolean is_organ_donor;
>   boolean needs_corrective_lenses;
>   key string drivers_license_number;
>   omit key US_Citizen::social_security_nubmer;
>   ...
>}
>
>Without the ability to omit keying material derived from the parent class,
>the state of Oregon would have to use SSN as a key, when they would rather
>just use the driver's license number.  Given some time, I could probably
>come up with a better example.
>
>Jamie