Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Higgins Data Model 2.0"
(→Entity Class) |
|||
Line 9: | Line 9: | ||
The Higgins data model (ontology) builds on the [[Context Data Model 1.1]] (CDM). It incorporates (without reinventing) 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 entity and attribute classes such as would be required to describe "email address", "first name", "calendar event", "friend", "student", "movie", "book", and so on. | The Higgins data model (ontology) builds on the [[Context Data Model 1.1]] (CDM). It incorporates (without reinventing) 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 entity and attribute classes such as would be required to describe "email address", "first name", "calendar event", "friend", "student", "movie", "book", and so on. | ||
− | The Higgins Data Model | + | The Higgins project is developing an extension to the Higgins Data Model called the [[Persona Data Model 1.1]]. See [[Data Models 1.1]] for a summary of these relationships. |
− | + | == Relationship to IdAS == | |
− | + | The Higgins Data Model is implemented by [[IdAS 1.1]]. Developers can extend and adapt IdAS by creating [[Context Provider]] plugins. These plugins implement their more specialized (concrete) data models by extending the Higgins model. | |
== Classes and Attributes == | == Classes and Attributes == |
Revision as of 05:52, 18 March 2010
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}Contents
Version 1.1
- This page describes version 1.1 of the Higgins Data Model
Relationship to other models
The Higgins data model (ontology) builds on the Context Data Model 1.1 (CDM). It incorporates (without reinventing) 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 entity and attribute classes such as would be required to describe "email address", "first name", "calendar event", "friend", "student", "movie", "book", and so on.
The Higgins project is developing an extension to the Higgins Data Model called the Persona Data Model 1.1. See Data Models 1.1 for a summary of these relationships.
Relationship to IdAS
The Higgins Data Model is implemented by IdAS 1.1. Developers can extend and adapt IdAS by creating Context Provider plugins. These plugins implement their more specialized (concrete) data models by extending the Higgins model.
Classes and Attributes
Entity Classes
Identity-related classes:
Agent
: An agent (eg. person, group, software or physical artifact).Group
: A class of Agents. Subclass ofAgent
Organization
: An organization. Subclass ofAgent
Person
: A contextualized aspect of a person. Subclass ofAgent
Misc utility classes:
TimeSpan
: A span of time.
Attribute Classes
Complex-valued attributes:
authority
: authority for this statement. Attribute of a statement. Value is anAgent
.correlation
: A directed relation between two entities (possibly in two different Contexts) that are asserted to be representing the same person, group, object or concept. Attribute of an entity. Value is an entity.creator
:Agent
that instantiated this statement. Attribute of a statement. Value is anAgent
member
: A relationship between a Group or Organization and its member Agent (the range). Sub-attribute ofpart
. Attribute of anGroup<code> or <code>Organization
. Value is anAgent
.memberOf
: The Group or Organization of which this Agent is a member. Sub-attribute ofpartOf
. Attribute of anAgent
. Value is aGroup
or anOrganization
.part
: A relationship between an aggregated whole (the domain) and a part of that whole (the range). Attribute of an entity. Value is an entity.partOf
: A relationship between a part (the domain) and an agregated whole (the range). Attribute of an entity. Value is an entity.timespan
: duration of time. Attribute of an entity. Value is an instance ofTimeSpan
.
Simple-valued attributes:
synonym
: Used as an abstract super-attribute to "tag" sub-attributes as being considered alternative identifiers for this entity. Attribute of an entity. Value is any simple value.validFrom
: beginning of a time duration. Attribute of aTimeSpan
. Value is anxsd:dateTime
.validTo
:xsd:dateTime
value. Attribute of aTimeSpan
. Value is anxsd:dateTime
Representation of Entity and Attribute Classes
There are two kinds of entities: instance entities (e.g. an instance of Clyde the elephant) and class entities (e.g. the concept of elephant). Similarly there are two kinds of attributes: instance attributes (e.g. the length of Clyde's trunk) and class attributes (e.g. the concept of trunk-length). This section describes class entities and class attributes.
Entity Class
Following RDF conventions, each instance entity is linked via an rdf:type
attribute to one or more class entities. The following attributes are used to describe a class entity:
- 1..1
rdfs:type
: value must berdf:Class
- 0..N
rdfs:subClassOf
: value must berdf:Class
- 0..1
rdfs:comment
: value is an internal (developer) string comment - 1..1
skos:prefLabel
: internationalized display label skos:prefLabel - 0..1
skos:prefSymbol
: internationalized display symbol (e.g. icon) skos:prefSymbol - 0..N
spin:constraint
: instances ofspl:Attribute
(see below)
Attribute Class
Attributes are described 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 Class
Global attribute definitions are entities with the following attributes:
- 1..1
rdf:type
: URI value must either beowl:DatatypeProperty
orowl:ObjectProperty
- 0..1
rdfs:domain
: URI value must be an Entity Class entity - 0..1
rdfs:range
: URI value must be an Entity Class entity, a DataRange, 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 - 1..1
skos:prefLabel
: internationalized display label skos:prefLabel - 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 ofskos:Concept. Indicates the skos:Concept category to which this attribute belongs.
- 0..N
rdfs:subPropertyOf:
the value must be another Attribute Class entity - 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:
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 .
Class-scoped Attribute Class
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 name of the attribute - 0..1
spl:maxCount
: max cardinality of this attribute. The maximum number of instances of this attribute on instances of the class whosespin:constraint
value is thisspl:Attribute
instance - 0..1
spl:minCount
: min cardinality as above. - 0..1
spl:defaultValue
: default value of the attribute - 0..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. It is also handy that these 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 two value types must not be in conflict.
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
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 ofPolicy
.
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 ofsubject
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 ofsubject
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 ofaccessControl
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 ofaccessControl
selfSubject
. If true, this policy's subject is implicitly defined as the current Idas consumer. Subattribute ofaccessControl
Subattributes of operation
:
add
: If not further restricted byonAttribute
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 byonAttribute
may be added or new values added.delete
: If not further restricted byonAttribute
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 byonAttribute
properties may be deleted.modify
: If not further restricted byonAttribute
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 byonAttribute
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 byonAttribute
properties may be read.
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.