|
|
| (73 intermediate revisions by 6 users not shown) |
| Line 1: |
Line 1: |
| − | ==Motivation==
| + | {{#eclipseproject:technology.higgins|eclipse_custom_style.css}} |
| | + | [[Image:Higgins_logo_76Wx100H.jpg|right]] |
| | | | |
| − | This work area falls under "The need for interoperability" described here: [http://www.eclipse.org/higgins/goals.php Higgins Goals]. In addtion, items #3 and #5 of the [http://www.eclipse.org/higgins/higgins-charter.php charter] state or imply the need for a robust identity and social networking data model:
| |
| − | : '''Scope item 3.''' Provide an API and data model for the virtual integration and federation of identity and security information from a wide variety of sources.
| |
| − | : '''Scope item 5.''' Provide a social relationship data integration framework that enables these relationships to be persistent and reusable across application boundaries.
| |
| | | | |
| − | ==Overview==
| + | The [[Data Model]] provides a common representation for identity, profile and relationship data to enable interoperability and data portability across heterogeneous sites and systems. The model is described in these sections: |
| − | At the highest level the goal of the data model is to provide a common representation for identity, profile and relationship data in order to provide interoperability.
| + | |
| | | | |
| − | Information fragmentation is a pervasive problem. Even seemingly simple activities depend on information from a number of heterogeneous sources. The information may be fragmented by physical location, device, application, middleware, data storage or platform. By providing a common data model, data from multiple locations and systems can be unified. | + | === Information Cards === |
| | + | The Information Card (aka I-Card) metaphor includes the end-user concept of [[I-Card]]s and an [[Identity Selector]] to manage them |
| | | | |
| − | Of course there are other approaches to data unification than providing a common data model. However every unification strategy involves choosing some kind of lowest common denominator. It is all a question of how low is low. The lower the level, the easier to do the unification, but the more lossy. For example, consider raw text. It's easy to index, search, and copy/paste but very lossy. Or consider XML, which offers a common syntax for describing a series of attributes of a given object and values for each of the attributes, although still without any defined semantics.
| + | === Tokens and Claims === |
| | + | Higgins supports identity service concepts such as Claim, Digital Identity, Security Token and other objects used by Identity Providers, Relying Parties, Service Providers and Identity Selectors |
| | | | |
| − | The kinds of data we wish to unify are very roughly classified as '''identity''', '''profile''' and '''relationship''' data. ''Identity'' information is related to identification, authentication, etc. ''Profile'' information can be preferences, interests, and associated objects like events and things, wishlists. ''Relationships'' can be any kind of associations between objects (typically between [[Digital Subject]]s) as well as affiliations.
| + | === Context Data Model === |
| | | | |
| − | An overview presentation on the data model can be found here: [http://www.eclipse.org/higgins/images/Higgins_Data_Model.ppt Higgins Data Model (PPT)]
| + | The [[Context Data Model 1.0]] describes a data model that can makes portable and interoperable data from heterogeneous data sources such as enterprise directories, databases, communications networks, and social networks |
| | | | |
| − | ===Kinds of interoperability===
| + | [[Category:Higgins Data Model]] |
| − | | + | |
| − | Saying we desire interoperability can mean many different things. At the least it should mean that we can navigate through and inspect data objects and their associated attributes/relationships within any [[Context]] through the Higgins API. This is part of what motivates [[Data Model Goals]] [2], [3] and [4]. At this level of interoperability we may not understand the meaning of the objects and the attributes, but we can know that they are there.
| + | |
| − | | + | |
| − | Moving further along the interoperability spectrum, if we add the requirement that every attribute/relationship is globally uniquely identifiable (see [5]in [[Data Model Goals]]) then we can use the Higgins IdAS API for more than a shallow syntactic parse of the data in various Contexts. We can, for example, assemble (join) attribute information about about two Digital Subjects held in two separate Contexts, and perhaps implemented by separate providers, without collision and data loss. Along these lines, Higgins itself needs to implement certain kinds of cross-Context attribute data flows for correlated [[Digital Subject|Digital Subjects]].
| + | |
| − | | + | |
| − | Beyond inspection and navigation, Higgins aspires to support applications that can also edit [[Context]] data. We envision Higgins-based applications with user interfaces that can manipulate data contained in any [[Context]] from any [[Context Provider]] bound into Higgins. This implies a number of things. First, we require that the semantics of the attributes of objects be defined in a single well-defined (unambiguous) manner. If the model has more degrees of freedom than the absolute minimum necessary, ambiguity will arise where different [[Context Provider|Context Providers]] express the same semantic in different ways. For more about this see [6] in [[Data Model Goals]].
| + | |
| − | | + | |
| − | Second, the ''specific'' schema of a [[Context|Context's]] use of the abstract Higgins data model must be exposed at the CPI and API levels. This exposure allows an application to know what the valid degrees of freedom in the structure of the data are, and the values of its data fields may assume. The application can learn from the schema what datatypes are used to describe the value of a given attribute (e.g. a string, a non-zero number or a date, etc). It can learn what kinds of attributes may optionally be added to an object (and which may not), etc. And it can learn or what kinds of required and/or optional relationships are allowed with objects of various kinds. For more about the need for a common schema language see [7] in [[Data Model Goals]].
| + | |
| − | | + | |
| − | ===Design Goals===
| + | |
| − | * [[Data Model Goals]] provides an an enumeration of the top level design goals that ultimately led to the decision to using an RDF/OWL-based metamodel.
| + | |
| − | | + | |
| − | ===The data model and IdAS ===
| + | |
| − | [[Context Provider]]s are plug-ins to the [[Identity Attribute Service]] (IdAS) Component used in many [[Deployments]]). They are responsible for data transformation between the Higgins model and their own internal data model. Higgins does not constrain the [[Context Provider|Context Provider's]] choice of data representation; it could be XML-based, object-oriented, relational, or anything else.
| + | |
| − | | + | |
| − | Here are some examples of some of the [[Context Provider|Context Providers]] envisioned:
| + | |
| − | * Directories: LDAP stores like eDirectory, Active Directory, OpenLDAP, etc...
| + | |
| − | * Relational databases used by enterprise apps to store identity/profile information.
| + | |
| − | * Digital social networks (node-edge graphs): data behind Facebook, MySpace, LinkedIn, etc; or the graphs created by mining email traffic
| + | |
| − | * Email/IM/collaboration client account data: email and IM client accounts, contact/buddy lists
| + | |
| − | * Identity/profile data stored in website "silos": personal information stored sites like eBay, Amazon, Google Groups, Yahoo Groups
| + | |
| − | | + | |
| − | ==Concepts used in the data model==
| + | |
| − | * [[Concepts]] --terms used in the data model
| + | |
| − | | + | |
| − | ==Higgins.owl==
| + | |
| − | * [[Higgins Ontology]] --summary of higgins.owl (aka HOWL) classes and properties
| + | |
| − | | + | |
| − | Example Context Schemas (based on higgins.owl):
| + | |
| − | * [[test-person Example Context Ontology]]
| + | |
| − | * [[Person-with-address Example Context Ontology]]
| + | |
| − | * [[Person-with-friend Example Context Ontology]]
| + | |
| − | | + | |
| − | ==Open Issues==
| + | |
| − | * [[Data Model Open Issues]]
| + | |
| − | ** [[LDAP Issues and To-Dos]] --open issues specifically related to LDAP schema
| + | |
| − | | + | |
| − | ==Reference==
| + | |
| − | ===RDF/OWL Related Resources===
| + | |
| − | * Intro to RDF/OWL: [[RDF-OWL Data Model]]
| + | |
| − | * Semantic Web (RDF/OWL) Resources
| + | |
| − | ** Toolkit: [http://www.wiwiss.fu-berlin.de/suhl/bizer/toolkits/ Developers Guide to Semantic Web Toolkits]
| + | |
| − | ** Reference documents: [http://www.w3.org/2001/sw/WebOnt/#Current W3C Web Ontology Working Group]
| + | |
| − | ** Tutorial: http://www.cs.man.ac.uk/~horrocks/ISWC2003/Tutorial/
| + | |
| − | * Normalization to OWL/RDF
| + | |
| − | ** [http://www.ldap.com/1/spec/schema/ont.shtml Schemat]
| + | |
| − | ** Sebastian Dietzold, Generating RDF Models from LDAP Directories (PDF) , [http://www.semanticscripting.org/SFSW2006/ 2nd Workshop on Scripting for the Semantic Web] co-located with the [http://www.eswc2006.org/ 3rd European Semantic Web Conference], June 12, 2006
| + | |
| − | | + | |
| − | ===Misc Resources===
| + | |
| − | * http://identityschemas.org
| + | |
| − | * "D3.2: Models" FIDIS, October, 2005, ([http://www.fidis.net/fileadmin/fidis/deliverables/fidis-wp2-del2.3.models.pdf PDF] 74 pages). Summary: "The objective of this document is to present in a synthetic way different models of representation of a person ("person schema") that can be used in different application domains.
| + | |
| − | * [http://www.nmi-edit.org/eduPerson/internet2-mace-dir-eduperson-200604.html eduPerson spex]
| + | |
| − | | + | |
| − | ==See Also==
| + | |
| − | * [[Higgins Wiki]]
| + | |
Higgins supports identity service concepts such as Claim, Digital Identity, Security Token and other objects used by Identity Providers, Relying Parties, Service Providers and Identity Selectors
