Skip to main content
Jump to: navigation, search

Difference between revisions of "Higgins Data Model 2.0"

(New page: {{#eclipseproject:technology.higgins|eclipse_custom_style.css}} right == Version 1.1 == * This page describes version 1.1 of the Higgins Data Model ==...)
Line 4: Line 4:
== Version 1.1 ==
== Version 1.1 ==
* This page describes version 1.1 of the Higgins Data Model
* This page describes version 1.1 of the Higgins Data Model
== Introduction ==
Although the CDM can be used for almost any kind of data, the focus of CDM is to provide a foundation for integrating, unifying, and sharing identity-related data. In particular we are focused on information about a person, a group or an entire organization. This might include contact information, authentication data, preferences, email addresses, interests, employer-related information. An object representing a single person, might have relationships to other objects and other people in the same or different data contexts.
* [ Higgins Data Model Intro (PPT)] for an overview.
* [[Context Data Model Background]] for information about motivations and design goals.
== CDM Core Semantics ==
The Context Data Model (CDM) encompasses the core semantics of the W3C's [ Resource Description Framework] (RDF); anything expressible in RDF is expressible in the CDM although the converse isn't true.
Most of the subtle but important differences between CDM and RDF are derived from differences in the choice of identifiers used to identify objects in each model. RDF is based on pure HTTP URIs, whereas CDM is based on a more generalized URI called a [[UDI]]. Objects identified by URIs in RDF are called ''Resources'', whereas in CDM they are identified by [[UDI]]s and are called [[Entity | Entities]].
The CDM includes a kind of object called a [[Context]] that has no analog in RDF. Individual [[Context]]s can be thought of as containers of portions of the overall graph of objects. [[Context]]s partition the data space into disjoint sets of objects. [[Context Provider]] plug-in implementations map data stored in a various kinds of data stores into objects within [[Context]] boundaries in CDM.
The CDM also differs from RDF on a syntactic (semantically lossless) level. In RDF an object may have N properties of type T each of which has a single value whereas in the CDM an object may only have 0..1 property of type T, and if the property exists it has 1..N values. Further, in the CDM these properties are called [[Attribute]]s.
== Key Concepts ==
== Key Concepts ==

Revision as of 14:49, 2 November 2009


Higgins logo 76Wx100H.jpg

Version 1.1

  • This page describes version 1.1 of the Higgins Data Model

Key Concepts

The Higgins data model add the following concepts to the Context Data Model 1.1.

  • The CDM is self-describing, recursive. We use special kinds of Entities called Entity Classes to describe classes of entities and we use other kinds of Entities called Attribute Classes that describe Attributes.
  • Speaking of recursive, there is Statement class that allows Attributes to be added to a (single) value of an Attribute of an Entity.


  • Getting into the weeds a bit, there is also a utility class called TimeSpan (and related Attributes: validFrom and validTo)


Building on the core described above, the CDM introduces the following slightly more specialized concepts:

  • There is an Entity class called Agent along with three subclasses: Group, Organization and Person.
  • Entities and Contexts can be correlated using the Entity Correlation and Context Correlation links respectively.
  • There are a set of pre-defined Attributes:
    • part, and its sub-attribute member
    • partOf, and its sub-attribute memberOf
  • The following Attributes are defined to describe Attributes: displayOrder, category, authority, lastModified, lastVerifiedFromSource, lastVerifyAttempt
  • Contexts can be correlated using the contextCorrelation Attribute

Access control

  • Starting in 1.1M4 we have defined a set of Entity Classes and Attributes that describe access control policies.
  • The new Entity classes are Policy, an abstract superclass for many kinds of policy we might want to model in the future, and AccessControl, a subclass of Policy
  • A new abstract super-attribute called accessControl is defined with these sub-attributes:
    • onAttribute
    • operation, and its sub-attributes: add, delete, modify and read
    • selfOperation, and its sub-attributes: selfAdd, selfDelete, selfModify, selfRead
    • selfSubject


The Higgins Data Model 1.1 is described by Higgins.owl 1.1. Higgins.owl 1.1 is an abstract (sometimes called an "upper") ontology for identity information. It is abstract in that it doesn't describe any concrete attributes such as "email address" or "first name". It also doesn't define very specialized classes of objects such as "calendar event" or "student", "movie", "book", etc. These are left to Context Providers to define for themselves.

Building on higgins.owl 1.1

Developers of Context Providers can create ontologies that are based on higgins.owl to describe specific concrete domains of relevance to Contexts of this Context Provider.

For example, if a developer wanted to describe a CRM database, they would create an OWL ontology that would describe the kinds of data objects and their attributes in the CRM database. This CRM database is called a Context. If, for example, the database contained records about customers and those customers had full-names and email addresses, then the developer would define "Customer" as a sub-class of the Agent class as defined in higgins.owl, and would define "full-name" and "email" as kinds of Attributes.

Back to the top