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.
Difference between revisions of "Node"
(Undo revision 91846 by Asafronkova.aquasoft.dp.ua (Talk)) |
|||
| Line 2: | Line 2: | ||
[[Image:Higgins_logo_76Wx100H.jpg|right]] | [[Image:Higgins_logo_76Wx100H.jpg|right]] | ||
== Introduction == | == Introduction == | ||
| − | This page describes the Higgins concept of [[ | + | This page describes the Higgins concept of [[Node]]. |
It is similar to the [http://wiki.idcommons.net/index.php/Digital_Subject Identity Gang Lexicon's definition of Digital Subject]. The term was changed to eliminate any possible confusion with the term subject (or data subject) in international privacy law. | It is similar to the [http://wiki.idcommons.net/index.php/Digital_Subject Identity Gang Lexicon's definition of Digital Subject]. The term was changed to eliminate any possible confusion with the term subject (or data subject) in international privacy law. | ||
| − | A Higgins [[ | + | A Higgins [[Node]] is a representation of an [[Entity]] ''within a given context.'' [[Node]]s and [[Entity | Entities]] are not the same concept. The distinction is subtle but critical. In Higgins the same [[Entity]] is usually represented by multiple [[Node]]s in different [[Context]]s. |
== Definition == | == Definition == | ||
* A digital representation of an [[Entity]] | * A digital representation of an [[Entity]] | ||
| − | * A [[ | + | * A [[Node]] has zero or more [[Attribute]]s |
== Details == | == Details == | ||
| − | * Although not strictly required, almost all [[ | + | * Although not strictly required, almost all [[Node]]s have a single [[NodeId]] [[Attribute]] in addition to whatever other kinds of [[Attribute]]s they may have. This [[NodeId]] [[Attribute]] has a value of type [[NodeId Data Range]] and uniquely identifies the [[Node]] within its containing [[Context]]. |
| − | * Some of the [[Attribute]]s of an [[ | + | * Some of the [[Attribute]]s of an [[Node]] may be references to other [[Node]]s in the same or different [[Context]]s. These are called [[Node Relation]]s. For example, an [[Node]] representing the [[Entity]] Bob may have a "knows" [[Node Relation]] [[Attribute]] pointing to an [[Node]] representing Bob's friend Alice. |
| − | * A single person (thing or concept) may be represented as one (or more) [[ | + | * A single person (thing or concept) may be represented as one (or more) [[Node]]s in one [[Context]] and (an)other [[Node]]s in other [[Context]]s. By linking or "federating" these disparate [[Node]]s one can gain a more unified view of a given person. [[Context]]s representing different systems, organizations and entire enterprises with widely varying storage and trust models are handled using this [[Node]] linking approach. For example the person "Bob Smith" could be represented as two [[Node]]s; the first having "bsmith" as an [[NodeId]] and the second having "bob" as a [[NodeId]]. These two [[Node]]s may be in the same or in different [[Context]]s. To express that the "bsmith" is the same person as "bob" an [[Node Correlation]] [[Attribute]] would be added to "bsmith" whose value points to "bob". |
| − | * [[Context]]s can be nested (e.g. enterprises have sub-organizations, and there are systems within an enterprise/org, etc.) or related through other means (employment/HR system vs. customer system where same person is a customer and an employee). Thus linking the [[ | + | * [[Context]]s can be nested (e.g. enterprises have sub-organizations, and there are systems within an enterprise/org, etc.) or related through other means (employment/HR system vs. customer system where same person is a customer and an employee). Thus linking the [[Node]]s relevant to those contexts provides an a broader view of a [[Node]]. |
| − | * The information contained in one [[ | + | * The information contained in one [[Node]] is not necessarily a pure subset of the union of all of the information contained in all of the linked [[Node]]s representing a person taken together. There is no consistency constraint imposed between the [[Node]]s of an person. For example, a person could be represented such that their name was Joe in one [[Node]] in one [[Context]] and JoAnn in another [[Node]] in another [[Context]]. |
| − | == | + | == Node Subclasses == |
| − | Each [[Context]] has an associated ontology/schema. This schema must import and build on the terms in HOWL. Within this ontology the [[Context]] can define its own [[ | + | Each [[Context]] has an associated ontology/schema. This schema must import and build on the terms in HOWL. Within this ontology the [[Context]] can define its own [[Node]] subclasses and [[Attribute]] types. When defining a [[Node]] subclass, the class definition can place restrictions on the cardinality of [[Attribute]] types also defined in the ontology. A given [[Node]] subclass: |
* MAY define the minimum cardinality of an [[Attribute]], that is, the minimum number of values allowed (e.g. >=3 values) | * MAY define the minimum cardinality of an [[Attribute]], that is, the minimum number of values allowed (e.g. >=3 values) | ||
** MAY define the maximum cardinality of an [[Attribute]], that is, the minimum number of values allowed (e.g. <=100 values) | ** MAY define the maximum cardinality of an [[Attribute]], that is, the minimum number of values allowed (e.g. <=100 values) | ||
| Line 29: | Line 29: | ||
== See Also == | == See Also == | ||
* [[ContextId]] | * [[ContextId]] | ||
| − | * [[ | + | * [[NodeId]] |
* [[Concepts]] | * [[Concepts]] | ||
[[Category:Higgins Concepts]] | [[Category:Higgins Concepts]] | ||
Revision as of 08:33, 11 April 2008
{{#eclipseproject:technology.higgins}}
Introduction
This page describes the Higgins concept of Node.
It is similar to the Identity Gang Lexicon's definition of Digital Subject. The term was changed to eliminate any possible confusion with the term subject (or data subject) in international privacy law.
A Higgins Node is a representation of an Entity within a given context. Nodes and Entities are not the same concept. The distinction is subtle but critical. In Higgins the same Entity is usually represented by multiple Nodes in different Contexts.
Definition
- A digital representation of an Entity
- A Node has zero or more Attributes
Details
- Although not strictly required, almost all Nodes have a single NodeId Attribute in addition to whatever other kinds of Attributes they may have. This NodeId Attribute has a value of type NodeId Data Range and uniquely identifies the Node within its containing Context.
- Some of the Attributes of an Node may be references to other Nodes in the same or different Contexts. These are called Node Relations. For example, an Node representing the Entity Bob may have a "knows" Node Relation Attribute pointing to an Node representing Bob's friend Alice.
- A single person (thing or concept) may be represented as one (or more) Nodes in one Context and (an)other Nodes in other Contexts. By linking or "federating" these disparate Nodes one can gain a more unified view of a given person. Contexts representing different systems, organizations and entire enterprises with widely varying storage and trust models are handled using this Node linking approach. For example the person "Bob Smith" could be represented as two Nodes; the first having "bsmith" as an NodeId and the second having "bob" as a NodeId. These two Nodes may be in the same or in different Contexts. To express that the "bsmith" is the same person as "bob" an Node Correlation Attribute would be added to "bsmith" whose value points to "bob".
- Contexts can be nested (e.g. enterprises have sub-organizations, and there are systems within an enterprise/org, etc.) or related through other means (employment/HR system vs. customer system where same person is a customer and an employee). Thus linking the Nodes relevant to those contexts provides an a broader view of a Node.
- The information contained in one Node is not necessarily a pure subset of the union of all of the information contained in all of the linked Nodes representing a person taken together. There is no consistency constraint imposed between the Nodes of an person. For example, a person could be represented such that their name was Joe in one Node in one Context and JoAnn in another Node in another Context.
Node Subclasses
Each Context has an associated ontology/schema. This schema must import and build on the terms in HOWL. Within this ontology the Context can define its own Node subclasses and Attribute types. When defining a Node subclass, the class definition can place restrictions on the cardinality of Attribute types also defined in the ontology. A given Node subclass:
- MAY define the minimum cardinality of an Attribute, that is, the minimum number of values allowed (e.g. >=3 values)
- MAY define the maximum cardinality of an Attribute, that is, the minimum number of values allowed (e.g. <=100 values)