Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Higgins XDI Harmonization"

(Issues)
(Introduction)
 
(82 intermediate revisions by the same user not shown)
Line 2: Line 2:
 
[[Image:Higgins_logo_76Wx100H.jpg|right]]
 
[[Image:Higgins_logo_76Wx100H.jpg|right]]
  
This document summarizes some of the notes and conversations that have happened today at the EIC conference. These are still rough notes, but I felt it would be good to share them all the same. The memo is organized by comparing Higgins CDM, HDM and PDM in turn with XDI/PDX.
+
This document summarizes some of the notes and conversations that started at the European Identity Conference in Munich.  
  
 
==Introduction==
 
==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.
+
Higgins speaks an XDI dialect that we'll call ''Higgins XDI''. The XDI community is developing a dialect of XDI called ''PDX XDI''. PDX is defined here http://wiki.oasis-open.org/xdi/PdxExample.
  
===Two kinds of graphs===
+
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.
  
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. In Higgins these graphs are separated first into multiple top-level contexts--the meta context and 0..n others. Within these contexts there may be sub-contexts [In the RDF-backed context providers these are implemented by RDF code that uses named graphs to model sub-contexts].
+
Markus had created a page very similar and related to this one here: [[IdAS XDI Mapping]].
  
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.
+
===Two kinds of graphs===
  
In order to make the graphs transformable we need to ensure that the semantics are equivalent between the two.
+
The [[Context Data Model 2.0 | CDM]], [[Higgins Data Model 2.0 | HDM]], and [[Persona Data Model 2.0 | PDM]] 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, we now need to focus on semantic differences between what the two kinds of graphs can represent.
+
With that as background, here are the kinds of issues we need to address:
 
+
===Issues to Resolve===
+
 
+
Kinds of issues to address:
+
  
 
# Semantics are undefined in PDX - need to add the semantics to PDX
 
# Semantics are undefined in PDX - need to add the semantics to PDX
Line 26: Line 22:
 
# Semantics are different but in a shallow or unimportant way - need to adopt one or the other  
 
# Semantics are different but in a shallow or unimportant way - need to adopt one or the other  
 
# Semantics are incompatible
 
# Semantics are incompatible
 +
# Non-issues: the semantics are equivalent and losslessly transformable back and forth
  
Reference
+
===CDM===
 +
====Global URIs====
 +
* In Higgins global URIs if resolvable, resolve to exactly one external description.
 +
*''Resolution'': Non issue. XDI is the same.
  
* Links to CDM, HDM and PDM are found here:
+
====Multiple values====
http://wiki.eclipse.org/Personal_Data_Store_Overview#Data_Models
+
*CDM allows multiple values of an attribute 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]]
  
==Issues==
+
====Identifying values====
 +
*In PDX you can identify individual values of an attribute with a persistent identifier that won't change when the value changes (and you can have order).
 +
*In CDM you cannot.
 +
*BTW, perhaps IdAS needs to support ordered values.
  
 +
=== HDM ===
  
 +
==== h:correlation  ====
  
 +
Semantics:
  
 +
*For privacy reasons h:correlation links are directed
 +
*The semantics are reversible except for the issue of privilege.
 +
*''Resolution'': <code>h:correlation</code> is the same as <code>$is</code>. '''--Paul: I'm not sure I buy this. Seems to me that $is is the same as owl:sameAs not h:correlation.'''
  
===CDM===
+
Cross-context usage:
# Global URIs
+
#* Global URIs if resolvable, resolve to exactly one external description.
+
#*Resolution: Non issue.
+
#CDM allows multiple values of an attribute.
+
#*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]]
+
  
5) 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.
+
*An entity in one context may be linked to entities in another context via an h:correlation link.
 +
*This is identical in XDI
 +
*''Resolution: they are the same''
  
Resolution: TBD Perhaps IdAS needs to support at least ordered values.
+
==== h:relation  ====
  
===HDM===
+
Semantics:
 +
* 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
 +
*''Resolution'':
  
#For privacy reasons h:correlations are directed.
+
==== h:indeterminate  ====
#*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)
+
  
2) 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.]
+
Semantics:
 +
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.  
 +
*''Resolution'':
  
Resolution: TBD.
+
==== Other complex-valued attributes ====
  
3) 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).
+
See [[Higgins Data Model 2.0#Classes_and_Attributes]] for other complex valued attributes beyond h:correlation:
  
4) Class descriptions. In HDM we define a number of attributes on classes to enable software to dynamically construct UIs, etc. Some of these are taken from the SPIN vocabulary. Others are from OWL and RDF.
+
Resolved:
  
Entity classes: agent, group, organization, person
+
*<code>part</code>: - same as $has
 +
*<code>partOf</code>: - same as $is$has
  
Attribute classes:
+
Still unresolved:  
authority - no equivalent in PDX
+
correlation - already discussed
+
creator - no equivalent in PDX
+
member - no equivalent in PDX
+
memberOf - no equivalent in PDX
+
part - no equivalent in PDX. Only used to support access control.
+
partOf - no equivalent in PDX
+
timeSpan - no equivalent in PDX. XDI has timestamps
+
synonym -
+
validFrom - no equivalent in PDX, but planned for access control and thus not yet used/implemented in Higgins
+
validTo - no equivalent in PDX,  but planned for access control and thus not yet used/implemented in Higgins
+
  
Entity Class
+
*<code>issuer</code>: - no equivalent in PDX
- rdfs:type - in XDI is $is$a
+
*<code>member</code> (sub-property of h:part): - no equivalent in PDX
- subclassOf - in XDI is $is$a
+
*<code>memberOf</code> (sub-property of h:partOf): - no equivalent in PDX
- rdf:comment - no equivalent in XDI
+
*<code>timespan</code>: - no equivalent in PDX. BTW, XDI has timestamps which is similar
- skos:prefLabel - no equivalent in XDI
+
- skis:prefSymbol: no equivalent is XDI
+
- spin:constraint (points to spl:Attribute) constraints on attributes of a specific Entity class
+
  + predicate  - the attribute we are talking about
+
  + maxCount - Markus thinks there is an equivalent in XDI  
+
  + minCount - Markus thinks there is an equivalent in XDI
+
  + defaultValue - need to add to XDI
+
  + valueType - Markus thinks this can be done for literals (e.g. +tel / $is$a / $xsd$string). And for object-valued predicates the valueType is implicit
+
  
Global Attributes
+
==== Simple-valued attributes ====
  
- rdf:type: URI value must either be owl:DatatypeProperty or owl:ObjectProperty
+
*<code>synonym</code>: - Joseph: this corresponds to some usages of $is
 +
*<code>start</code>: - same as $d$first&nbsp;
 +
*<code>end</code>: - same as $d$last&nbsp;
  
Resolution: Markus: you can tell in XDI if it is a literal valued because you'll see a $foo $is$a statement
+
==== Entity Class ====
  
- 0..1 rdfs:domain: URI value must be an Entity Class entity
+
The following two must be dealt with together. It appears that an examination of surrounding context (on the XDI side) is required to disambiguate.
 +
*rdfs:type (instance to class; recommended on each instance) - in XDI is $is$a
 +
*rdfs:subclassOf (class to class) - in XDI is $is$a
  
Resolution: XDI $has is the inverse of rdf:domain; this should suffice
+
Others:
 +
*rdf:comment - Joseph: this is equivalent to "<-- comment -->" in XDI (however the proposed JSON mapping of XDI does not support comments)
 +
*skos:prefLabel (as opposed to rdf:label of which there may be many) - no equivalent in XDI (confirmed by Joseph)
 +
*skos:prefSymbol (e.g. an icon of a telephone next to a telephone number in a UI) - no equivalent is XDI
 +
*owl:disjointWith
  
- 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.)
+
''Attribute Restrictions''
- 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
+
The following additional attributes are used to define characteristics of a specific attribute of an entity class:
- lots of predicates and classes designed but not yet implemented in Higgins
+
  
5) rdf:type is recommended on each entity instance
+
*owl:maxCardinality:
 +
*owl:minCardinality:
 +
*owl:cardinality:
 +
*owl:hasValue:
 +
*owl:someValuesFrom:
 +
*owl:allValuesFrom:
 +
*spl:defaultValue:
  
Resolution: $is$a is the XDI equivalent to rdf:type. The Higgins AS can map back and forth.
+
==== Attributes ====
  
=== PDM ===
+
*rdf:type:
# URI conventions
+
**Resolution: Markus: you can tell in XDI if it is a literal valued because you'll see a $foo $is$a statement
#*In PDM an entityId is is a URI UDI that is either absolute or relative (# fragment) by syntactic inspection.
+
*rdfs:domain:
#* Resolution: Non issue. In XDI a relative XRI is (by definition) relative to the XDI within the context that contains it
+
**Resolution: - XDI $has is the inverse of rdf:domain; this should suffice
#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.
+
*rdfs:range: -
#*Resolution: [[Attribute Service 2.0]] will map between representations. [It already does this]
+
*skos:description: -
 +
*skos:prefLabel: -
 +
*skos:prefSymbol: -
 +
*skos:example - an example value
 +
*h:category: -
 +
*rdfs:subPropertyOf: -
 +
*rdfs:label: -
 +
*rdfs:comment: -
  
 +
==== Access Control  ====
  
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.
+
*lots of predicates and classes designed but not yet implemented in Higgins
 +
*In Higgins we consider XDI 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).
  
Resolution: TBD.
+
==== Entity classes ====
  
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.
+
*Agent
 +
**Person
 +
*Group
 +
*Organization
  
Resolution: TBD.
+
=== PDM ===
 
+
====URI conventions====
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.
+
*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
Resolution: Higgins could adopt the PDX approach.
+
====Multi-contextual Person====
 
+
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.
4) Persona nodes have explicit class Persona. In XDI persona nodes are of various types "+person", "+home+person", etc.
+
*''Resolution'': [[Attribute Service 2.0]] will map between representations. [It already does this]
  
Resolution: TBD
+
====Root persona====
 +
In PDM there is a root <code>h:Person</code> 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.
  
5) Persona nodes have a Persona human readable label string. In XDI this not required.
+
====MetaMe-to-sub-entities====
 +
* In Higgins we use h:correlation from the MetaMe <code>h:Person</code> node to each/all (sub-)<code>h:Person</code> nodes.  
 +
* In PDX $has$a is used sometimes and $is in other cases.
  
Resolution: TBD
+
====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. Perhaps Higgins could adopt the PDX approach.
  
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.
+
====Persona Contexts, typed contexts====
  
Resolution: TBD
+
The set of <code>h:correlation</code>, <code>h:relation</code>, and <code>h:indeterminate</code> links define a multi-entity graph explicitly. This allows software to know how to navigate and process the graph. This means that software that ONLY knows these 3 predicates can ignore all others and still walk the graph.
  
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)
+
====Misc====
 +
* PDM uses vCard [w3c 2010 member submission] except for tel URI telephone numbers. An <code>h:Person</code> node effectively "is" a vCard (we don't use explicit vCard classes). Not sure I see the point here.
  
Resolution: TBD
+
====i-cards====
 +
* 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.
  
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.
+
====Other PDM attribute classes====
 +
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. PDM also defines some classes not found elsewhere like PaymentMethod
  
Resolution: TBD
+
== PDX ==
  
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.
+
This section looks at [http://wiki.oasis-open.org/xdi/PdxExample PDX] and tries to find equivalent terms in CDM, HDM, or PDM.
  
Resolution: TBD.
+
=== Dollar Words ===
  
10) PDM defines some classes not found elsewhere like PaymentMethod
+
$d$first
 +
* dateTime when this subject was created
 +
* in HDM hasn't been defined
  
Resolution: TBD.
+
$d$last
 +
* dateTime when this subject was last modified
 +
* in HDM hasn't been defined

Latest revision as of 13:49, 24 June 2010

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

Higgins logo 76Wx100H.jpg

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. PDX is defined here http://wiki.oasis-open.org/xdi/PdxExample.

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.

Markus had created a page very similar and related to this one here: IdAS XDI Mapping.

Two kinds of graphs

The CDM, HDM, and PDM 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

  • CDM allows multiple values of an attribute 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 individual values of an attribute with a persistent identifier that won't change when the value changes (and you can have order).
  • In CDM you cannot.
  • BTW, perhaps IdAS needs to support ordered values.

HDM

h:correlation

Semantics:

  • For privacy reasons h:correlation links are directed
  • The semantics are reversible except for the issue of privilege.
  • Resolution: h:correlation is the same as $is. --Paul: I'm not sure I buy this. Seems to me that $is is the same as owl:sameAs not h:correlation.

Cross-context usage:

  • An entity in one context may be linked to entities in another context via an h:correlation link.
  • This is identical in XDI
  • Resolution: they are the same

h:relation

Semantics:

  • 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
  • Resolution:

h:indeterminate

Semantics: 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.

  • Resolution:

Other complex-valued attributes

See Higgins Data Model 2.0#Classes_and_Attributes for other complex valued attributes beyond h:correlation:

Resolved:

  • part: - same as $has
  • partOf: - same as $is$has

Still unresolved:

  • issuer: - no equivalent in PDX
  • member (sub-property of h:part): - no equivalent in PDX
  • memberOf (sub-property of h:partOf): - no equivalent in PDX
  • timespan: - no equivalent in PDX. BTW, XDI has timestamps which is similar

Simple-valued attributes

  • synonym: - Joseph: this corresponds to some usages of $is
  • start: - same as $d$first 
  • end: - same as $d$last 

Entity Class

The following two must be dealt with together. It appears that an examination of surrounding context (on the XDI side) is required to disambiguate.

  • rdfs:type (instance to class; recommended on each instance) - in XDI is $is$a
  • rdfs:subclassOf (class to class) - in XDI is $is$a

Others:

  • rdf:comment - Joseph: this is equivalent to "<-- comment -->" in XDI (however the proposed JSON mapping of XDI does not support comments)
  • skos:prefLabel (as opposed to rdf:label of which there may be many) - no equivalent in XDI (confirmed by Joseph)
  • skos:prefSymbol (e.g. an icon of a telephone next to a telephone number in a UI) - no equivalent is XDI
  • owl:disjointWith

Attribute Restrictions

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

  • owl:maxCardinality:
  • owl:minCardinality:
  • owl:cardinality:
  • owl:hasValue:
  • owl:someValuesFrom:
  • owl:allValuesFrom:
  • spl:defaultValue:

Attributes

  • rdf:type:
    • Resolution: Markus: you can tell in XDI if it is a literal valued because you'll see a $foo $is$a statement
  • rdfs:domain:
    • Resolution: - XDI $has is the inverse of rdf:domain; this should suffice
  • rdfs:range: -
  • skos:description: -
  • skos:prefLabel: -
  • skos:prefSymbol: -
  • skos:example - an example value
  • h:category: -
  • rdfs:subPropertyOf: -
  • rdfs:label: -
  • rdfs:comment: -

Access Control

  • lots of predicates and classes designed but not yet implemented in Higgins
  • In Higgins we consider XDI 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).

Entity classes

  • Agent
    • Person
  • Group
  • Organization

PDM

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

Multi-contextual Person

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.

Root persona

In PDM there is a root h:Person 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.

MetaMe-to-sub-entities

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

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. Perhaps Higgins could adopt the PDX approach.

Persona Contexts, typed contexts

The set of h:correlation, h:relation, and h:indeterminate links define a multi-entity graph explicitly. This allows software to know how to navigate and process the graph. This means that software that ONLY knows these 3 predicates can ignore all others and still walk the graph.

Misc

  • PDM uses vCard [w3c 2010 member submission] except for tel URI telephone numbers. An h:Person node effectively "is" a vCard (we don't use explicit vCard classes). Not sure I see the point here.

i-cards

  • 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.

Other PDM attribute classes

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. PDM also defines some classes not found elsewhere like PaymentMethod

PDX

This section looks at PDX and tries to find equivalent terms in CDM, HDM, or PDM.

Dollar Words

$d$first

  • dateTime when this subject was created
  • in HDM hasn't been defined

$d$last

  • dateTime when this subject was last modified
  • in HDM hasn't been defined

Back to the top