Re: [provision] Relationship models

[Gary P Cole <Gary.P.Cole@sun.com>]

Darran Rolls wrote:

> 2 - Do we support multiple relationships between the same PSO's,  for 
> example can a given PSO-ID be involved in more than one containment 
> relationship and more than one reference relationship?

ONLY ONE PARENT IN CONTAINMENT RELATIONSHIPS
I believe that the nature of containment (i.e., hierarchy) implies that 
each object can have only one parent.

ANY NUMBER OF REFERENTS IN REFERENCE RELATIONSHIPS
I believe that reference in general is arbitrary, and that any object 
can therefore refer to any number of objects.  For example, a Group 
object could refer to any number of objects (e.g., via a reference 
relationship type called "hasMember").  For that matter, any object that 
can belong to a Group may belong to *multiple* groups (e.g., via a 
reference relationship type called "belongsToGroup").

RELATIONSHIP CARDINALITY
If there is any need to restrict the cardinality of a particular 
relationship type, then the definition of a reference relationship type 
should specify a "cardinality" attribute.  This might be one of:
- 0+  // zero or more; an optional relationship to any number of 
referents (the default)
- 1?  // zero or one; an optional relationship to exactly one referent
- 1    // exactly one; a required relationship to exactly one referent
- 1+  // one or more; a required relationship to at least one referent
- N   // a required relationship to exactly N referents
- N? // an optional relationship to exactly N referents

In practice, I've only ever seen the first four (0+, 1?, 1, 1+).

REFLEXIVE RELATIONSHIPS
The two reference relationship types mentioned above (i.e., "hasMember" 
and "memberOf" ) could be implemented as two *views* of the same 
relationship type.  Since these are basically inverses, an 
implementation could represent one with a reverse lookup on the other.  
However, I believe that this is up to the implementation (and that we 
should therefore not specify it).

MULTIPLE TYPES OF REFERENCE RELATIONSHIPS.
This seems fairly obvious, but then that's my forte. :-) Any object 
should be able to participate in more than one *type* of reference 
relationship.  For example, an Account object may belong to any number 
of Groups, but may also have any number of Roles.  These might be 
represented as two different relationship types: "memberOf" and 
"hasRole".  Both would be optional and multivalued (that is the default 
cardinality suggested above).

Gary

ps.  That ought to get things off to a good start!