Merging subtype constraints (again)

Ed Barkmeyer edbark at nist.gov
Mon May 13 12:43:07 EDT 2002


Phil Spiby wrote:

> Abstract supertype is not the same as TOTAL_OVER! 

Agreed.  Now I agree that it is only vaguely related.

> When converting from E2 -> E1 
> abstract supertypes should be moved into the entity they affect.

Yes, in fact ABSTRACT should be declared with that entity in the first place!
I don't believe that ABSTRACT should be declared in a SUBTYPE_CONSTRAINT at all,
ever!  ABSTRACT is a part of the conceptual intent of the entity type and should
be declared when the type is originally declared.  (Among other things, it
alters the rules for the types of attributes the entity may have.)  If another
schema interfaces a type that is not declared to be ABSTRACT, i.e. was intended
to be instantiable as such, and then declares it ABSTRACT (in a
SUBTYPE_CONSTRAINT), what does that mean?  Is it actually interfacing the entity
type?  or just using its declaration as a model for a new type?  Or is it a
compaction of the interfaced type with a new abstract entity type that always
has exactly one of those things?  Or is it a lazy way to write a TOTAL_OVER
constraint?  As long as we're enforcing good modeling practice, let's not create
yet another muddled notion that encourages bad models!  Put another way, when
would anyone *need* to declare an entity-type ABSTRACT in a SUBTYPE_CONSTRAINT?

Moving the ABSTRACT declaration may create some problems with interfacing,
unless we agree that only long-form E1 schemas will result!

In fact, I'm not sure about the impact on interfaces generally, e.g.:
 SCHEMA schema1;
 ENTITY thing; ... END_ENTITY;
 END_SCHEMA;

 SCHEMA schema2;
 USE FROM schema1 (thing);
 SUBTYPE_CONSTRAINT things_are_abstract FOR thing;
  ABSTRACT;
 END_SUBTYPE_CONSTRAINT;
 ENTITY snark SUBTYPE OF (thing); ... END_ENTITY;
 END_SCHEMA;

 SCHEMA schema3;
 USE FROM schema1 (thing);
 USE FROM schema2 (snark);
 ...
 END_SCHEMA;

Is thing independently instantiable under schema3?
Or is thing implicitly declared ABSTRACT when schema3 interfaces snark?
(The definition of snark itself has nothing to do with the "abstractness" of
thing.)

!!! We need to describe the implicit/explicit interface of SUBTYPE_CONSTRAINTs
in clause 11 (interfacing)!  A SUBTYPE_CONSTRAINT usually relates to more types
than appear in its FOR list, and  should only be implicitly interfaced if *all*
of those types are interfaced (like the RULE that it replaces)!

The following example has the same problem:

> Total_overs can only be converted into global rules, there is no other way
> to ensure the semantics is maintained. So
> 
> SUBTYPE_CONSTRAINT gender_constraint FOR person;
>   TOTAL_OVER (male, female);
> END_SUBTYPE_CONSTRAINT;
> 
> should map to:
> 
> RULE gender_constraint FOR (person);
> WHERE
>   WR1: SIZEOF(QUERY(p <* person | SIZEOF(TYPEOF(p) *
> ['SCHEMANAME.MALE','SCHEMANAME.FEMALE']) = 0)) = 0
> END_RULE;

This doesn't quite work.  In a (gender-blind) schema that interfaces Person but
not Male or Female, this rule will be implicitly interfaced, and will fail!  
This can be fixed by including male and female in the FOR list of the RULE.

But better is to get rid of the TYPEOF junk altogether. 
I suggest that the above TOTAL_OVER constraint should map to:

 RULE gender_constraint FOR (person, male, female);
 WHERE
   WR1: person = male + female;
 END_RULE;

which says the same thing in a way that can be interpreted by humans, 
interfaced correctly, implemented by software without contrivance (e.g. 
Expresso), and actually used to perform deductions, if you are into 
ontological models.

Do we have a draft of the E2->E1 mapping annex somewhere?  
(Dave Price had a sketch draft 2 years ago!)

-Ed


-- 
Edward J. Barkmeyer                       Email: edbark at nist.gov
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Mail Stop 8260          Tel: +1 301-975-3528
Gaithersburg, MD 20899-8260               FAX: +1 301-975-4482

"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority."



More information about the wg11 mailing list