| RE: EntityId decision analysis page (was RE:[higgins-dev]entityIDnot an attribute?) |
|
Thanks to Jim and David for the responses.
I updated the wiki page and then copied the relevant portion of the page below so
we can continue discussing in email. There are now four questions. Answers from
Jim, David, and myself are reflected for all four. See also the proposal I
added at the end. Please do add your own answers/proposals, either
in reply to this email or on the wiki. =Drummond === Q1: Unique Identifier vs. Attribute
Set === Must a Higgins [[EntityId]] be a
single-part CUID or GUID, or can it be a multi-part set of [[Attribute]]s? * Jim: Yes - it must be a CUID or GUID. * David: No - ''I prefer a multi-part key
where the parts of the key might also be unique in a context. An example is a
EntityID made up of a uniqueName, uniqueId, nativeName, nativeId. Any part of
the of the Entity ID could be used to identify the object.'' * Drummond: Abstain - ''Single-part IDs
are easier, but multi-part keys are useful too.'' === Q2: Representation of an EntityId as a
Unique Identifier === If an [[EntityId]] is a unique identifier,
should this be represented as: #1 A type of [[Attribute]]? #2 An inherent property of an [[Entity]]
that MAY be exposed as an [[Attribute]]? * Jim: #2 * David: #2 * Drummond: #2 === Q3: Cardinality === What is the cardinality of [[EntityId]]?
(The answer may depend on the answer to #2.) #1 0..n? #2 0..1? #3 1 (whose value may be null)? #4 None of the above? * Jim: Abstain - ''I tend to want
simple.'' * David: #1 or #2 - ''0..1 if the EntityId
is mutlipart as in Q1. 0..n if it is a string, and then it needs a type.'' * Drummond: #4 - ''See comment below.'' === Q4: Mutability === Is the EntityID of an Entity immutable? # Yes? # No? # Depends? * Jim: Yes - ''I believe it must be as
soon as we start tying policy to EntityIDs. Either that, or we need to require
a way to ensure referential integrity for places where EntityIDs are stored in
policy statements.'' * David: Depends - ''My vote on Q1 was
multipart where the decomposition could contain both mutable (uniqueName) and
immutable (uniqueId) parts. They both have their use cases. If the EntityID is
a string, then 1..n is needed to accomodate mutable, immutable types and if the
id can be used in other protocols (compatability with legacy systems).'' * Drummond: Depends - ''See comment
below''. == Comments/Proposals == === Drummond === It seems we're overloading [[EntityId]] -
one property can't meet all the requirements. A proposal would be to use two
properties: # '''CUID:''' ## Cardinality of 1, but whose value can
be null (representing a blank node). ## Immutable. ## Not exposed as an [[Attribute]]. # '''EntityId:''' ## Cardinality 0..n ## Mutable by default; immutability
denoted by an attribute on this attribute. ## Exposed as an [[Attribute]] if present. |