Higgins Data Model 2.0

This page describes version 2.0 of the Higgins Data Model.

Files

• Most recent published
• SVN source: higgins.owl

Introduction

The Higgins data model (ontology) builds on the Context Data Model 2.0 (CDM). It incorporates 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 personal data. It doesn't describe concrete entity and attribute classes such as would be required to describe "email address", "first name", "calendar event", "friend", "student", "movie", "book", and so on.

Note: We are developing a concrete ontology for personal data based on HDM 2.0. It called the Persona Data Model 2.0. See Personal Data Store_Overview#Data_Models for a summary of these relationships.

Relationship to IdAS

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

Classes

Agent

An agent (e.g. person, group, software or physical artifact).

Group

A class of Agent.

• SubClassOf Agent

Organization

An organization.

• SubClassOf Agent

Person

A contextualized aspect of a person.

• SubClassOf Agent

TimeSpan

A span of time.

Context

A singleton instance that represents the file or container of a set of regular entities.

• subClassOf: owl:Ontology
• 0..1 control
• 1..1 vocabulary

Complex-valued Attributes

control

Link to a context that contains information (e.g. access control policies) that controls this one.

• domain: Context
• value: Context

correlation

: A relation between two entities in different contexts that are asserted to be representing the same thing (person, group, object or concept). Symmetric attribute of an entity. Value is an entity.

• relation: A directed relation between two entities (possibly in two different contexts) that are asserted to NOT be representing the same person, group, object or concept. No level of reciprocity is assumed, i.e. relation(a, b) does not imply relation(b, a). The opposite of correlation.
• Sub-attribute of owl:differentFrom
• domain: entity
• value: entity

indeterminate

A directed relation between two entities (possibly in different contexts) for which it is unknown as to whether they represent the same (person, group, object or concept) thing or a different thing.

• domain: entity
• value: entity

issuer

Issuer of this context.

• domain: Context
• value: xsd:anyURI

The issuer is the party that, more than any other party defines the context. By defines we mean things like defining the overall vocabulary to describe the context, defining the set of terms (attributes) within this overall vocabulary that are used by entities in the context, and defining the access control policies for the context.

The issuer is, with one exception, the party that manages the persistent data storage for the context. The exception is that if the the party is an agent of the user (and works entirely on the user's behalf) then the user and not the hosting provider agent is considered the issuer.

Note that the issuer is necessarily the authoritative source of the values of attributes in the context. In some cases another party other than the issuer (e.g. the user) is authoritative over all of the values of attributes. In some cases the issuer truly is authoritative over all of the values of attributes of entities in the context. And most cases are somewhere in between.

Some examples...

In the case of an LDAP directory that is represented as a context, the issuer of the context would be the enterprise department that runs and manages the directory. In this case there would be many entities representing the many person entries in the directory. Different people would have different levels of access to attributes of their (and other) entry-entity. These permissions may be based on group or role membership, etc.

A similar case would be a context that represents the hundreds of millions of entities (people) in the Facebook social network. Each person has the ability to read and update most of the attributes about their particular entity (the entity that represents them), and much more limited access over the entities of other people. The issuer of this context would be Facebook--since it is Facebook that defines the set of attributes that is used, the access control policies, etc.

Another case would be an context that represents an Information Card issued by a credit agency. The agency would define the context such that it contains a single entity that represents the card holder, and define a single attribute whose value represents that person's credit score. The issuer in this case is the credit agency.

At the other end of the spectrum imagine a context that represents a person's address book. In this case the context contains a 100 entities representing the person's 99 friends as well as an entity to represent themselves. Since the user are doing all the manual data entry, is the authoritative source for all attribute values. The user most likely instantiated the entire context from a template that defined the set of attributes in each address book record. And although the user probably didn't define this template, the fact that the user chose the template is our justification for considering the user to the be issuer.

member

A relationship between a Group or Organization and its member Agent (the range).

• sub-attribute of part.
• domain: Group<code> or <code>Organization.
• value: Agent

memberOf

The Group or Organization of which this Agent is a member.

• sub-attribute of partOf.
• domain: Agent.
• value: a Group or an Organization.

part

A relationship between an aggregated whole (the domain) and a part of that whole (the range).

• domain: an entity
• value: an entity.

partOf

A relationship between a part (the domain) and an aggregated whole (the range).

• domain: an entity
• value: an entity.

timespan

Duration of time.

• domain: an entity.
• value: an instance of TimeSpan.

vocabulary

The ontology that this Context is based on. Single valued. By convention regular Higgins contexts contain only data instances--they do not contain entity class nor attribute class definitions. All classes of entities and attributes must be defined in a single, external vocabulary file/context. This external vocabulary context may in turn import one or more other vocabularies.

• domain: Context
• value: owl:Ontology

Simple-valued attributes

synonym

Used as an abstract super-attribute to "tag" sub-attributes as being considered alternative identifiers for this entity.

• domain: an entity.
• value: any simple value.

start

Beginning of a time duration.

• domain: TimeSpan
• value: an xsd:dateTime.

end

End of a time duration.

• domain: TimeSpan
• value: a xsd:dateTime

Class Entities

We define two kinds of entities: instance entities (e.g. an instance of Clyde the elephant) and class entities (e.g. the concept of elephant that describes the set of all elephants). We refer to class entities simply as classes.

Each instance (entity) is linked via an rdf:type attribute to one or more classes. The following attributes are used to describe that class:

• 1..1 rdf:type: value must be rdf:Class
• 0..N rdfs:subClassOf: value must be rdf:Class
• 0..1 rdfs:comment: value is an internal (developer) string comment
• 0..1 skos:description: string value that describes the attribute. Used for tooltip text in UIs
• 1..1 skos:prefLabel: internationalized display label skos:prefLabel
• 0..1 skos:prefSymbol: internationalized display symbol (e.g. icon) skos:prefSymbol

Attribute Restrictions

The following additional attributes are used to define characteristics of a specific attribute of an entity class:

• 0..1 owl:maxCardinality: value is a literal non-negative integer
• 0..1 owl:minCardinality: value is a literal non-negative integer
• 0..1 owl:cardinality: value is a literal non-negative integer
• 0..1 owl:hasValue: value is some value
• 0..1 owl:someValuesFrom: value is entity class
• 0..1 owl:allValuesFrom: value is an entity class
• 0..1 spl:defaultValue: value is some value

Attribute Definitions

Attribute Definitions define the attributes of an attribute:

Required:

• 1..1 rdf:type: URI value must either be subclass of owl:DatatypeProperty or owl:ObjectProperty
• 1..1 skos:prefLabel: internationalized display label skos:prefLabel

Optional:

• 0..1 rdfs:domain: URI value must be an Entity Class entity
• 0..1 rdfs:range: URI value must be an Entity Class entity, an RDF Datatype (possibly with constraining facets), or one of the allowed XML Schema datatypes (e.g. xsd:string, etc.)
• 0..1 skos:description: string value that describes the attribute. Used for tooltip text in UIs
• 0..1 skos:prefSymbol: internationalized display symbol (e.g. icon) skos:prefSymbol
• 0..1 skos:example - an example value
• 0..1 h:category: value must be an instance of skos:Concept. Indicates the skos:Concept category to which this attribute belongs.
• 0..N rdfs:subPropertyOf: the value must be another Attribute Definition entity (e.g. owl:differentFrom)
• 0..1 rdfs:label: internal (ontology developer) display label
• 0..N rdfs:comment: internal (ontology developer) comment

Example:

Here is an example (in the p: namespace) of an alternative phone number complex-valued attribute:

 p:otherPhone
     rdfs:comment "An alternative telephone number"@en ;
     rdfs:label "Other phone"^^xsd:string ;
     rdfs:range p:telephoneURI ;
     h:category p:account-attribute ;
     skos:prefLabel "Other telephone"@en .

The following OWL:objectProperties may be referenced (e.g. as the value of rdfs:subPropertyOf):

• owl:differentFrom
• owl:SymmetricProperty
• owl:AsymmetricProperty
• owl:FunctionalProperty
• owl:InverseFunctionalProperty

Attribute Concepts

As described above an attribute may have a h:category attribute whose value must be a an instance of skos:Concept in a concept schema. The idea is to provide additional metadata about the nature of an attribute.

Implementation note: The skos:prefLabel values of these skos:Concept instances can be used to dynamically create dynamically driven user interfaces that logically group attributes into consistent categories.

Access Control

The following classes and attributes are experimental.

Classes

• Policy: an abstract superclass for many kinds of policy we might want to model in the future.
• AccessControl: Policy related to Access Control and data sharing. Subclass of Policy.

Attributes

• accessControl: Abstract super-attribute.
• subject: If present on an Access Control Policy instance the policy is restricted to apply only to this attribute.
• agentSubject: Attribute relation indicates what Agent or class of Agents is the subject of the Policy. Subattribute of subject
• groupSubject: Attribute relation indicates what Agents are the subject of the Policy by specifying a Group or super-Group, iteratively, the Agents are a member of. Subattribute of subject
• onAttribute: If present on an Access Control Policy the policy is restricted to apply only to the type of property indicated by the range of this relation within the Entity or set of Entities indiated by this Policy's operation relation. Subattribute of accessControl
• operation: Abstract operation allowed on an entity or a class of entities. Range is an entity instance or a class of entities that define the scope of resource for this Access Control Policy. The scope may be further restricted by the addition of onAttribute properties to only specified Attributes of this entity or class of entities. Subattribute of accessControl
• selfSubject. If true, this policy's subject is implicitly defined as the current Idas consumer. Subattribute of accessControl

Subattributes of operation:

• add: If not further restricted by onAttribute properties, then new instances of the class of Entity indicated by the range may be added to the Context. If restricted, then a new instance of the kinds of properties/attribute(s) specified by onAttribute may be added or new values added.
• delete: If not further restricted by onAttribute properties, then instances of the class of Entity indicted by the range may be deleted from the Context. If restricted, then some or all of the values of the kind(s) of properties/attribute(s) specified by onAttribute properties may be deleted.
• modify: If not further restricted by onAttribute properties, then instances of the class of Entity indicated by the range may be arbitrarily modified. If restricted, then some or all of the values of the kind(s) of properties/attribute(s) specified by onAttribute properties may be modified.
• read: If not further restricted by onAttribute properties, then instances of the class of Entity indicted by the range may be read. If restricted, then some or all of the values of the kind(s) of properties/attribute(s) specified by onAttribute properties may be read.

How to use higgins.owl

Developers of Context Provider developers can create ontologies that are based on higgins.owl to describe specific concrete domains of relevance to their context provider. For example, if a developer wanted to describe a CRM database, they would create their own OWL ontology that imports higgins.owl and that describes the kinds of data objects and 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, and so on.

See Also

• Context Data Model 2.0
• Persona Data Model 2.0