Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "EntityId Requirements"

(second draft)
(inserted comments from mailing list and added proposal)
Line 3: Line 3:
  
 
== About ==
 
== About ==
This page is for discussing/documenting the terminology, requirements, and design decisions for [[EntityId]]s.
+
This page is for working out the requirements and design decisions for Higgins [[EntityId]]s.
  
 
== Content Data Model Requirements ==
 
== Content Data Model Requirements ==
In terms of the underlying graph model, following is a summary of the abstract requirements derived in a recent (2008-09-11) thread on the email list. The first step is determining if there is consensus about these requirements. '''Please post a note with your wiki signature if you disagree with any of the following:'''
+
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:'''
  
 
# 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.
 
# 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.
 
# There MAY be 0..n such arcs referencing the node. (0 is possible for blank nodes.)
 
# There MAY be 0..n such arcs referencing the node. (0 is possible for blank nodes.)
 
# An arc MAY theoretically be represented as either:
 
# An arc MAY theoretically be represented as either:
## A unique identifier.
+
## A unique identifier (single-part key).
## A set of [[Attribute]]s of that [[Entity]], none of which itself is required to be a unique identifier.
+
## A set of [[Attribute]]s of that [[Entity]] (multi-part key) - none of which itself is required to be a unique identifier.
 
# If the arc is represented as a unique identifier:
 
# If the arc is represented as a unique identifier:
## It MUST be locally unique within the [[Context]], and it MAY be globally unique across all [[Context]]s).
+
## 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).
  
 
== Higgins API Requirements ==
 
== Higgins API Requirements ==
The second step, based on the above requirements, is answering the following questions with respect to the Higgins API. '''Please post your votes/answers (with your wiki signature).'''
+
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).''
  
=== #1: Unique Identifier vs. Attribute Set ===
+
=== Q1: Unique Identifier vs. Attribute Set ===
Should the Higgins API constrain an [[EntityId]] to be a unique identifier, or can it be a set of [[Attribute]]s?
+
Must a Higgins [[EntityId]] be a single-part CUID or GUID, or can it be a multi-part set of [[Attribute]]s?
  
=== #2: Representation of an EntityId as a Unique Identifier ===
+
* 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:
 
If an [[EntityId]] is a unique identifier, should this be represented as:
 
# A type of [[Attribute]]?
 
# A type of [[Attribute]]?
# A separate property of an [[Entity]] that MAY be exposed as an [[Attribute]]?
+
# An inherent property of an [[Entity]] that MAY be exposed as an [[Attribute]]?
# Inherent in the definition of an [[Entity]]?
+
  
=== #3: Cardinality ===
+
* Jim: #2
 +
* David: #2
 +
* Drummond: #2
 +
 
 +
=== Q3: Cardinality ===
 
What is the cardinality of [[EntityId]]? (The answer may depend on the answer to #2.)
 
What is the cardinality of [[EntityId]]? (The answer may depend on the answer to #2.)
 
# 0..n?
 
# 0..n?
 
# 0..1?
 
# 0..1?
 
# 1 (whose value may be null)?
 
# 1 (whose value may be null)?
 +
# 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.

Revision as of 20:59, 12 September 2008

{{#eclipseproject:technology.higgins}}

Higgins logo 76Wx100H.jpg

About

This page is for working out the requirements and design decisions for Higgins EntityIds.

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).

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).

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 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.

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?

  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 - 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:

  1. CUID:
    1. Cardinality of 1, but whose value can be null (representing a blank node).
    2. Immutable.
    3. Not exposed as an Attribute.
  2. EntityId:
    1. Cardinality 0..n
    2. Mutable by default; immutability denoted by an attribute on this attribute.
    3. Exposed as an Attribute if present.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.