Difference between revisions of "Higgins XDI Harmonization"

Revision as of 14:23, 10 June 2010

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

This document summarizes some of the notes and conversations that started at the European Identity Conference in Munich.

Introduction

Higgins speaks an XDI dialect that we'll call Higgins XDI. The XDI community is developing a dialect of XDI called PDX XDI. There is no need or reason to have Higgins XDI "standardized" and in fact over time we hope to gradually adjust the Higgins code (mostly in the Attribute Service and client components, but possibly one or two minor changes to IdAS itself) so that it is conformant with the PDX XDI dialect.

Two kinds of graphs

The PDM/HDM/CDM models (see Personal_Data_Store_Overview under data models) taken together define the types of graphs that will be found in production Higgins-based systems. On the other hand the XDI defines the types of graphs that will be found in XDI conformant systems. So we have two kinds of graphs with differences between them. Our goal is to ensure that these graphs can be losslessly transformed bi-directionally. Our goal is NOT to make them the same graphs. In order to make the graphs transformable we need to ensure that the semantics are equivalent between the two.

With that as background, here are the kinds of issues we need to address:

1. Semantics are undefined in PDX - need to add the semantics to PDX
2. Semantics are undefined in Higgins - need to add the semantics to Higgins
3. Semantics are different but in a shallow or unimportant way - need to adopt one or the other
4. Semantics are incompatible
5. Non-issues: the semantics are equivalent and losslessly transformable back and forth

CDM

Global URIs

• In Higgins global URIs if resolvable, resolve to exactly one external description.
• Resolution: Non issue. XDI is the same.

Multiple values of an attribute.

• CDM allows this but XDI does not.
• Resolution: This can be mapped into a sub-context (in XDI) and back out losslessly. This is already implemented in the Attribute Service 2.0

Identifying values

• In PDX you can identify values with a persistent identifier that won't change when the value changes (and you can have order).
• In CDM you cannot.
• Perhaps IdAS needs to support ordered values.

HDM

For privacy reasons h:correlations are directed.

• The semantics are reversible except for the issue of privilege.
• Resolution: h:correlation is the same as $is (although there is another wrinkle mentioned below about h:correlation)

A single local entity may be linked to a single external (global) entity via an h:correlation link.

• I believe this is different from PDX wherein an interstitial LinkContract entity is inserted.

Link Contracts.

• In Higgins we consider Link Contracts to be attributes associated with a context. If a single entity is being shared, then it would be placed in its own context and the link contract metadata attached to the context (not the entity).

Complex-valued attributes:

• issuer: - no equivalent in PDX
• correlation: - already discussed ($is)
• member: - no equivalent in PDX
• memberOf: - no equivalent in PDX
• part: - no equivalent in PDX
• partOf: - no equivalent in PDX
• timespan: - no equivalent in PDX. XDI has timestamps

Simple-valued attributes:

• synonym:
• validFrom:
• validTo:

Entity Class

• rdfs:type - in XDI is $is$a
• subclassOf - in XDI is $is$a
• rdf:comment - no equivalent in XDI
• skos:prefLabel - no equivalent in XDI
• skis:prefSymbol: no equivalent is XDI
• to be written add the OWL restrictions (cardinality, values, etc.)

Attributes

• rdf:type: URI value must either be owl:DatatypeProperty or owl:ObjectProperty
  • Resolution: Markus: you can tell in XDI if it is a literal valued because you'll see a $foo $is$a statement
• 0..1 rdfs:domain: URI value must be an Entity Class entity
  • Resolution: XDI $has is the inverse of rdf:domain; this should suffice
• 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 skis:example - an example value
• ..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 Class entity
• 0..1 rdfs:label: internal (ontology developer) display label
• 0..N rdfs:comment: internal (ontology developer) comment

Access Control

• lots of predicates and classes designed but not yet implemented in Higgins

5) rdf:type is recommended on each entity instance

Resolution: $is$a is the XDI equivalent to rdf:type. The Higgins AS can map back and forth.

Entity classes

• Agent
  • Person
• Group
• Organization

PDM

1. URI conventions
   • In PDM an entityId is is a URI UDI that is either absolute or relative (# fragment) by syntactic inspection.
   • Resolution: Non issue. In XDI a relative XRI is (by definition) relative to the XDI within the context that contains it
2. Higgins represents a single person as a meta context + 0..N other contexts. XDI represents a single person as a single XDI document which can have multiple personas.
   • Resolution: Attribute Service 2.0 will map between representations. [It already does this]

1) There is a root persona node of fixed name "MetaMe". In XDI there is an "account root" i-number (globally resolvable). This would change from one PDS to another PDS.

Resolution: TBD.

2) In Higgins we use h:correlation from the MetaMe to each/all (sub-)Personas. In PDX $has$a is used sometimes and $is in other cases.

Resolution: TBD.

3) Inheritance. In PDX attributes are inherited "down" the graph. You can override an attribute on a lower Persona. If a lower Persona is shared, then the "upper" / inherited attributes would be pushed to the subscriber.

Resolution: Higgins could adopt the PDX approach.

4) Persona nodes have explicit class Persona. In XDI persona nodes are of various types "+person", "+home+person", etc.

Resolution: TBD

5) Persona nodes have a Persona human readable label string. In XDI this not required.

Resolution: TBD

6) Persona graph: The set of h:correlation and foaf:knows links define the persona graph explicitly. This allows software to know how to navigate and process the graph. This means that software that ONLY knows these two predicates can ignore all others and still walk the graph. In Higgins h:correlation links are ONLY used between persona (not more generally). Code relies on the this fact to be able to navigate the entire graph without understanding deeper structure of the nodes. So a h:correlation will not be used WITHIN a persona node & related sub-graph.

Resolution: TBD

7) PDM uses vCard [w3c 2010 member submission] except for tel URI telephone numbers. A Persona node effectively "is" a vCard (we don't use explicit vCard classes)

Resolution: TBD

8) PDM includes the icard.owl vocabulary. These are a set of attributes and values that are associated with context instances. A context is a card. For personal cards the context contains the entity whose attributes/values are the claims/values of the card. For managed cards the context contains an entity whose attributes/values are the claims/values of the display token retrieved from the card's associated STS.

Resolution: TBD

9) PDM defines some attributes not found in vCard, FOAF, etc. these include notions of p:home, p:work, p:receiving, etc.. These don't exist in PDX.

Resolution: TBD.

10) PDM defines some classes not found elsewhere like PaymentMethod

Resolution: TBD.