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

Context Data Model 2.0

Revision as of 18:07, 2 July 2008 by Paul.socialphysics.org (Talk | contribs) (The HOWL Ontology)

{{#eclipseproject:technology.higgins}}

Higgins logo 76Wx100H.jpg

Version 1.1

  • This page describes the Higgins 1.1 Context Data Model
  • See Context Data Model 1.0 for the Higgins 1.0 version

Introduction

Although it can be used for almost any kind of data, the focus of the Context Data Model (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.

See:

Core Semantics

The Context Data Model encompasses the core semantics of the W3C's Resource Description Framework (RDF); anything expressible in RDF is expressible in the Context Data Model although the converse isn't true.

Most of the subtle but important differences between Context Data Model 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 Context Data Model is based on a more generalized URI called a UDI. Objects identified by URIs in RDF are called Resources, whereas in Context Data Model they are identified by UDIs and are called Entities.

Context Data Model includes a kind of object called a Context that has no analog in RDF. Individual Contexts can be thought of as containers of portions of the overall graph of objects. Contexts partition the data space into disjoint sets of objects. Context Provider plug-in implementations map sets of data resources stored in a various kinds of data stores into objects within Context boundaries in the Context Data Model

Context Data Model 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 Context Data Model an object may only have 0..1 property of type T, and if the property exists it has 1..N values. Further, in Context Data Model these properties are called Attributes.

Key Concepts

The Context Data Model defines these (listed alphabetically) concepts:

  1. Attribute
  2. Context
  3. ContextId
  4. Context Relation
  5. Context Correlation
  6. Data Range
  7. Entity
  8. EntityId
  9. Entity Relation
  10. Entity Correlation

The HOWL 1.1 Ontology

The Context Data Model provides a description of its own model in OWL 1.1. This description is called HOWL 1.1 (higgins.owl). Due to the differences between RDF and Context Data Model mentioned above, this description is only an approximation, albeit a very useful one. It enables Higgins developers to use RDF and OWL tools and technologies in the development of Higgins applications and Context Providers without any modifications.

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

Extending HOWL

Developers must create specialized ontologies based on HOWL that describe specific concrete domains.

For example, if a developer wanted to describe a CRM database, she would create an OWL ontology that would describe the data objects in the CRM database. This CRM database is called a Context in Higgins. 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 Entity and "full-name" and "email" as kinds of Attributes.

Misc

Back to the top