Skip to main content
Jump to: navigation, search

Difference between revisions of "EntityId Requirements"

(Comments/Proposals)
(general update)
Line 3: Line 3:
  
 
== About ==
 
== About ==
This page is for working out the requirements and design decisions for Higgins [[EntityId]]s.
+
This page is for working out the requirements and design decisions for any changes to Higgins [[EntityId]]s in the migration from the [[Context Data Model 1.0]] to the [[Context Data Model 1.1]].
  
 
== Content Data Model Requirements ==
 
== Content Data Model Requirements ==
Line 16: Line 16:
 
## It MUST be a Contextually Unique ID (CUID), i.e., locally unique within the [[Context]].
 
## It MUST be a Contextually Unique ID (CUID), i.e., locally unique within the [[Context]].
 
## It MAY be globally unique identifier (GUID) (note that all GUIDs are by definition CUIDs provided that the Context recognizing them as IDs).
 
## It MAY be globally unique identifier (GUID) (note that all GUIDs are by definition CUIDs provided that the Context recognizing them as IDs).
 +
# With regard to mutability:
 +
## At least one identifier for an [[Entity]] in a [[Context]] SHOULD be immutable, i.e., serve as a persistent reference to the Entity within that Context (forever).
 +
## However because Higgins does not control Contexts or Context policies, the CDM must be prepared that an identifier for an Entity MAY be mutable, i.e., may be reassigned in that Context to reference a different Entity.
  
 
== Higgins API Requirements ==
 
== Higgins API Requirements ==
Following are the key design decisions we need to make. ''Drummond is posting votes as they are made in email. Feel free post your votes/comments directly (with your wiki signature).''
+
Following are the key design decisions we need to make. ''We are posting votes as they are made in email. Feel free post your votes/comments directly (with your wiki signature).''
  
 
=== Q1: Unique Identifier vs. Attribute Set ===
 
=== 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?
+
Must a Higgins [[EntityId]] be a single-part CUID or GUID, or could it be a multi-part key consisting of a set of [[Attribute]]s?
  
 
* Jim: Yes - it must be a CUID or GUID.
 
* 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.''
 
* 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.''
 
* Drummond: Abstain - ''Single-part IDs are easier, but multi-part keys are useful too.''
 +
* Tony: No.
 +
* Tom: Yes - it must be a CUID or GUID.
  
 
=== Q2: Representation of an EntityId as a Unique Identifier ===
 
=== Q2: Representation of an EntityId as a Unique Identifier ===
Line 35: Line 40:
 
* David: #2
 
* David: #2
 
* Drummond: #2
 
* Drummond: #2
 +
* Tony: #2
 +
* Tom: #2
  
 
=== Q3: Cardinality ===
 
=== Q3: Cardinality ===
Line 45: Line 52:
 
* Jim: Abstain - ''I tend to want simple.''
 
* 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.''
 
* 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.''
+
* Drummond: #2 or #3 - ''For comparison's sake, you need to always get the same identifier value. But there should also be a way to get all synonyms.''
 +
* Tony: #1
 +
* Tom: Abstain - ''+1 to Jim's feedback.''
  
 
=== Q4: Mutability ===
 
=== Q4: Mutability ===
Line 55: Line 64:
 
* 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.''
 
* 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).''
 
* 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''.
+
* Drummond: Depends - ''Both immutable and mutable SHOULD be possible. Best practice is to assign 1 immutable in any context and then allow 0..n synonyms (mutable or immutable). But Higgins does not control contexts so it seems like it must be open to either. However there should be a way to ask for an immutable identifier, or ask if an given identifier is mutable.''
 +
* Tony: No position yet.
 +
* Tom: Yes - ''+1 to Jim's position.''
  
== Proposals ==
+
== Current EntityId Definition in Context Data Model 1.0 ==
 +
The '''entityId''' parameter to the '''getEntity''' method on IContext interface:
 +
# Is of type [need info here].
 +
# Has cardinality 0..1
 +
# MUST be [[Context]]-unique; MAY be globally unique.
 +
# Is always exposed as an [[Attribute]].
 +
# Exposes no information about mutability.
  
So far the following looks like the proposal that would satisfy all requirements for uniquely referencing an [[Entity]] in a [[Context]] EXCEPT the requirement to accommodate a multi-part key:
+
== Proposed Changes in Context Data Model 1.1 ==
# '''entityId''' parameter to '''getEntity''' method on IContext interface:
+
## MUST be [[Context]]-unique; MAY be globally unique.
+
## MAY be formatted as a UDI.
+
## Cardinality 0..n
+
## MAY be mutable - use getEntityIdsMutable() method to discover mutability.
+
## MAY exposed as an [[Attribute]] if present; SHOULD be exposed as an [[Attribute]] if they are mutable so they can be modified if necessary.
+
# '''getEntityIdsMutable()''' method on IContext interface:
+
## Returns Boolean that tells you whether EntityIds in that [[Context]] are mutable or not. True = mutable.
+
  
We still need to discuss the requirement of a multi-part key.
+
=== #1: Not Require EntityId to be Exposed as an Attribute ===
 +
The proposed change is to make [[EntityId]] OPTIONAL to expose as an [[Attribute]]. Contexts that do not want to expose the [[EntityId]] can omit it from the list of [[Attribute]]s for an [[Entity]]. ''Note: if the [[EntityId]] is mutable, it SHOULD be exposed as an [[Attribute]] so it can be modified.''
 +
 
 +
=== #2: Add getEntityIdsMutable Method ===
 +
The proposed change is to add a '''getEntityIdsMutable()''' method on IContext that returns a Boolean indicating whether [[EntityId]]s in that [[Context]] are mutable or not. True = mutable.
 +
 
 +
=== #3: Add getIdentifiers Method ===
 +
The proposed change is to add a '''getIdentifiers()''' method on IEntity that returns all Identifiers for an Entity (0..n). By definition all such identifiers would be synonyms of the EntityId, even if the EntityId was not among the values returned.
 +
 
 +
== Still Under Discussion ==
 +
 
 +
=== #4: Multi-Part Keys ===
 +
The proposal is to keep it simple by requiring multi-part keys to be serialized into a composite identifier, which can then be used as an inherent EntityId or exposed as an Identifiers value.

Revision as of 23:29, 15 September 2008

{{#eclipseproject:technology.higgins}}

Higgins logo 76Wx100H.jpg

About

This page is for working out the requirements and design decisions for any changes to Higgins EntityIds in the migration from the Context Data Model 1.0 to the Context Data Model 1.1.

Content Data Model Requirements

In terms of the underlying graph model, following is a summary of the abstract requirements based on recent threads on the email list (~2008-09). Please post a note if you disagree with any of the following:

  1. An Entity is a node in the graph described by the Higgins Context Data Model. The CDM needs a consistent way of representing arcs referencing that node.
  2. There MAY be 0..n such arcs referencing the node. (0 is possible for blank nodes.)
  3. An arc MAY theoretically be represented as either:
    1. A unique identifier (single-part key).
    2. A set of Attributes of that Entity (multi-part key) - none of which itself is required to be a unique identifier.
  4. If the arc is represented as a unique identifier:
    1. It MUST be a Contextually Unique ID (CUID), i.e., locally unique within the Context.
    2. It MAY be globally unique identifier (GUID) (note that all GUIDs are by definition CUIDs provided that the Context recognizing them as IDs).
  5. With regard to mutability:
    1. At least one identifier for an Entity in a Context SHOULD be immutable, i.e., serve as a persistent reference to the Entity within that Context (forever).
    2. However because Higgins does not control Contexts or Context policies, the CDM must be prepared that an identifier for an Entity MAY be mutable, i.e., may be reassigned in that Context to reference a different Entity.

Higgins API Requirements

Following are the key design decisions we need to make. We are posting votes as they are made in email. Feel free post your votes/comments directly (with your wiki signature).

Q1: Unique Identifier vs. Attribute Set

Must a Higgins EntityId be a single-part CUID or GUID, or could it be a multi-part key consisting of a set of Attributes?

  • 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.
  • Tony: No.
  • Tom: Yes - it must be a CUID or GUID.

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
  • Tony: #2
  • Tom: #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: #2 or #3 - For comparison's sake, you need to always get the same identifier value. But there should also be a way to get all synonyms.
  • Tony: #1
  • Tom: Abstain - +1 to Jim's feedback.

Q4: Mutability

Is the EntityID of an Entity immutable?

  1. Yes?
  2. No?
  3. 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 - Both immutable and mutable SHOULD be possible. Best practice is to assign 1 immutable in any context and then allow 0..n synonyms (mutable or immutable). But Higgins does not control contexts so it seems like it must be open to either. However there should be a way to ask for an immutable identifier, or ask if an given identifier is mutable.
  • Tony: No position yet.
  • Tom: Yes - +1 to Jim's position.

Current EntityId Definition in Context Data Model 1.0

The entityId parameter to the getEntity method on IContext interface:

  1. Is of type [need info here].
  2. Has cardinality 0..1
  3. MUST be Context-unique; MAY be globally unique.
  4. Is always exposed as an Attribute.
  5. Exposes no information about mutability.

Proposed Changes in Context Data Model 1.1

#1: Not Require EntityId to be Exposed as an Attribute

The proposed change is to make EntityId OPTIONAL to expose as an Attribute. Contexts that do not want to expose the EntityId can omit it from the list of Attributes for an Entity. Note: if the EntityId is mutable, it SHOULD be exposed as an Attribute so it can be modified.

#2: Add getEntityIdsMutable Method

The proposed change is to add a getEntityIdsMutable() method on IContext that returns a Boolean indicating whether EntityIds in that Context are mutable or not. True = mutable.

#3: Add getIdentifiers Method

The proposed change is to add a getIdentifiers() method on IEntity that returns all Identifiers for an Entity (0..n). By definition all such identifiers would be synonyms of the EntityId, even if the EntityId was not among the values returned.

Still Under Discussion

#4: Multi-Part Keys

The proposal is to keep it simple by requiring multi-part keys to be serialized into a composite identifier, which can then be used as an inherent EntityId or exposed as an Identifiers value.

Back to the top