Difference between revisions of "Higgins Data Model 2.0"

Revision as of 05:07, 3 November 2009

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

Version 1.1

• This page describes version 1.1 of the Higgins Data Model

Introduction

The Higgins data model (ontology) builds on the Context Data Model 1.1. It reuses concepts from the OWL, SKOS, and SPIN ontologies to provide meta modeling capabilities. Although building on CDM, the Higgins data model is still an abstract (sometimes called an "upper") ontology for identity information. It doesn't describe concrete attributes such as "email address", "first name", "calendar event", "student", "movie", "book", etc.

The Higgins Data Model is implemented by IdAS 1.1. Developers can extend and adapt IdAS by creating Context Provider plugs. These CPs implement their more specialized (concrete) data models by extending the Higgins data model.

Entity Classes

Following RDF conventions each entity instance is linked via an rdf:type attribute to one or more entities that describe explicit classes the instance states that it instantiates.

Attributes of an Entity Class

The following attributes are used by entity classes:

• 1..1 rdf:class: value must be rdf:Class
• 0..1 rdfs:comment: developer comments
• 1..1 skos:prefLabel: internationalized display label
• 0..1 spin:constraint: instances of spl:Attribute

Attribute Classes

Attributes are modeled using two separate mechanisms: globally scoped and class scoped. All attributes must be defined by a globally scoped definition. Some may also be class scoped.

Global Attribute Definitions

Global attribute definitions are entities with the following attributes:

• 1..1 rdf:type URI value must either be owl:DatatypeProperty or owl:ObjectProperty
• 0..1 rdfs:domain URI value must be an Entity Class definition
• 0..1 rdfs: range URI value defines the datatype (as defined by OWL)
• 0..1 skos:description a string that describes the attribute. Used for tooltip text in UIs
• 0..1 skos:prefLabel the preferred internationalized display label
• 0..1 skos:example the value is an example value
• 0..1 h:category the value must be an instance of skos:Concept
• 0..N rdfs:subPropertyOf the value must be another attribute

Example:

Here is an example (in the p: namespace) of an alternative phone number:

 p:otherPhone
     a       owl:ObjectProperty ;
     rdfs:comment "An alternative telephone number"@en ;
     rdfs:domain p:Persona ;
     rdfs:label "Other phone"^^xsd:string ;
     rdfs:range p:telephoneURI ;
     h:category p:account-attribute ;
     r-card:appId "An alternative telephone number"@en ;
     vs:term_status "testing" ;
     skos:prefLabel "Other telephone"@en .

Note: the above doesn't show an example value

Class-scoped Attribute Definitions

The class scoped attribute definitions allows attributes to have metadata that is associated with the attribute when used within the scope of a particular class.

The first are the instances of spl:Attribute mentioned in the previous section describing Entity Classes. These spl:Attributes have the following attributes:

• 1..1 spl:predicate: the value of this attribute
• 0..1 spl:maxCount: max cardinality of this attribute. The maximum number of instances of this attribute on instances of the class whose spin:constraint value is this spl:Attribute instance
• 0..1 spl:minCount: min cardinatlity as above.
• 1..1 spl:valueType: datatype URI. May be literal (e.g. xsd:string) or may be entity-valued

Note: Those familiar with OWL will realize that we are not using the OWL-defined conventions for expressing cardinality. The SPIN-based alternatives are more natural and are directly supported by OWL development tools from TopBraid to provide run-time constraint checking.

Conflicting value type attributes in Global vs. Class-scoped Attribute Classes

The value type of an attribute may be specified by the rdfs:range attribute of a global Attribute Classes and as the spl:valueType attribute of a Class-scoped attribute class instance. If both are specified the values must not be in conflict.

Concept Hierarchies

As described above attributes should have h:concept attributes whose value must be a skos:Concept in a concept hierarchy.

The skos:prefLabels of these skos:Concept instances can be used to dynamically create dynamically driven user interfaces

New Classes and Attributes =

The Higgins data model defines these more specialized concepts:

• There is an Entity class called Agent along with three subclasses: Group, Organization and Person.
• The Statement class allows Attributes to be attached to a (single) value of an Attribute of an Entity.
• A utility class called TimeSpan (and related Attributes: validFrom and validTo)
• 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
• 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

Building on higgins.owl

The Higgins Data Model 1.1 is described by the file 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.