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.
Persona Data Model 2.0
The Persona Data Model 2.0 (PDM) is builds on Higgins Data Model 2.0 and a number of other models (aka schemas, vocabularies, ontologies). It used by Personal Data Store 2.0 and will likely be used by future Higgins web services.
Contents
- 1 Introduction
- 2 A graph of Persona nodes
- 3 Persona.owl
- 4 Vocabularies Imported by persona.owl
- 5 vCard
- 6 FOAF
- 7 WSG84
- 8 SKOS
- 9 event.owl
- 10 mapping.owl
- 11 payment.owl
- 12 icard.owl
- 13 rcard.owl
- 14 app-data.owl
- 15 Restrictions on CDM 2.0 EntityIds
- 16 See Also
Introduction
The Persona Data Model 2.0 is an ontology about people. It is based on the Higgins Data Model 2.0 which is in turn based on Context Data Model 2.0 (aka CDM 2.0). This page provides an informal overview.
A graph of Persona nodes
A person is represented as a graph of p:Persona
class Entity nodes (vertices) interconnected by links (edges). Each node represents a different facet of the user (person). Each node is an entity (i.e. a set of attributes & values). These attributes may be simple literals (e.g. the user's first name) or they may be other entities. These latter complex attributes are rendered a as links (edges) to other nodes, but these edges and nodes are not considered part of the graph.
The graph is a logical abstraction. The data behind these nodes may be physically located anywhere on the Internet.
Typically each node in the Persona graph is located in its own Context. The root node lies in a special context (for each user) called the root context.
All of the main persona entities can be reached by traversing links of the following kinds, (although other links may also exist (e.g. p:source
, foaf:knows
, etc.)):
h:correlation
h:relation
h:indeterminate
p:subCorrelation
p:subCorrelation and Access Control
PDM adds p:subCorrelation
, a specialized (directed) h:correlation
. It is a relation between two Personas in different contexts that are asserted to be representing the same person and such that the value entity is used in a broader scope (with generally more relaxed access control policies). The size of the intended "audience" for the value entity is typically larger than the intended audience for the source entity. It is a non-symmetric attribute of an entity. The value of this attribute is another entity.
SubCorrelation allows us to construct a directed graph of entities radiating out from the root node. The root node's attributes are the most privileged information about a person. Below is an example of a directed graph. We have displayed a reasonable "default" access control policy for each "level" (i.e. number of hops from the root) of the graph.
More detailed example graph
A more detailed example graph is shown below. In order to simplify the above diagram we follow a convention whereby the links are drawn between contexts whereas in reality the links are between the main p:persona
objects within each of these contexts. Further, these main persona entities may well themselves have complex attributes (i.e. links to other entities). These have also been omitted.
Vocabularies
In the above example all of the contexts except one express their contents using the Persona Data Model (vocabulary) (shown as purple "PDM"s above). The exception is the managed i-card from Equifax which uses attribute (aka claim) URIs defined by the OASIS IMI TC and by the ICF's (Information Card Foundation) schema working group.
Linked Contexts
A "consuming" persona in one context (e.g. the profile context shown below) may be linked to a "source" persona in another context. This is done by linking the personas with a p:source
link (complex-valued attribute). When the persona nodes in two contexts are linked in this way, this is an example of "linked contexts."
These p:source
links allow a single consuming persona node to aggregate one or more other persona nodes (usually of differing p:role
values) from other contexts. This promotes reuse of personas and contexts and minimizes copying and duplication. For example a "recipient" persona in one context might hold a name, address and phone number that correspond to a physical address, say the person's home. If the user uses this home address in 100 Profile Contexts (e.g. 100 eCommerce websites) each of these 100 context's main personas can have a p:source link to this shared home persona & context, rather than having 100 copies of this persona in each of the 100 contexts.
Every p:source link also has an inverse link p:consumer pointing in the opposite direction. For clarity these "back" links are not shown above. Any persona with more than one "incoming" p:source link (or, said another way more than one outgoing "p:consumer" link) is essentially a "shared" persona. Updating a shared persona has the effect of altering the attribute values that will be returned by the contexts that use a shared persona as a source.
At present these p:source and p:consumer links are used only to link persona entities, not entities in general.
Access Control
Attribute-level Access Control
The rules governing access to attributes in context C1 are defined in an external "control" context C2 where C2 is an instance of Mapping Context. Mapping Contexts also contain other rules unrelated to access control.
@@@@to be completed
Persona-level Access Control and Linked Contexts
In addition to the Attribute-level Access Controls, a user agent can potentially have write access to a context if:
- the user agent is the issuer of the context (e.g. it created the context in the first place)
- the persona to be edited is not linked to by any personas in contexts whose issuer is other than the user agent
Representing Social Graphs
h:relation
HDM defines a h:relation
complex attribute that is used in PDM to link one Persona
node to another where each Persona
node represents a different person. No symmetry is implied in this thus the statement (A h:relation
B) is akin to saying person A "knows of" person B.
Shown below are two social graph examples. One uses foaf:knows
links and and (unrelated to this) shows each node in its own context. The other uses h:relation
links and (unrelated) shows all persona nodes in a single context. In the Work context we see that the user knows three colleagues but doesn't know how they know one another. In the Home & Family context we see that the user knows two people and that everyone knows one another. The foaf:knows
links are shown in both directions although logically this is redundant since foaf:knows
is what is a called a symmetric relation.
Nodes that represent the user are shown in purple. Nodes representing a person other than the user are shown in red.
foaf:knows
To indicate that a person A "knows" person B where some level of reciprocated interaction between the parties is implied, we use foaf:knows.
Since foaf:knows is a broader concept than h:relation, foaf:knows is not a sub-attribute of h:relation. Thus if we had the statement "A h:relation B" then we might later add a second statement "A foaf:knows B" to add the stronger, broader (and symmetric) concept of "knowing."
h:indeterminate
HDM also defines h:indeterminate
link attribute on node A to indicates that its value(s) may or may not represent the same thing as is represented by A.
Implementation Note
Consumers of the HDM may traverse h:relation
, h:correlation
and h:indeterminate
attribute links and (despite ignoring all other links) traverse the entire graph of h:Persona
nodes.
Persona.owl
This is the main vocabulary at the heart of the Persona Data Model 2.0
UML Overview
Classes
Persona
A contextualized aspect (aka facet) of a person.
- subClassOf
h:Person
- subClassOf
geo:SpatialThing
- 0..N
subCorrelation
- 0..N
hasAgent
- 0..N
source
Role
Abstract concept of a role that a Persona
plays.
Internal
Roles that a person may play
- subClassOf
Role
Defined instances:
Work
: A work-related role.Home
: Acting in a personal, non-professional capacity.Buyer
: A person who is physically able to receive a bill and pay a bill. This person must be "contactable" to play this role. They must have a v:adr and v:n and optionally other information so that the bill/invoice can be physically delivered to them. Further, they must be able to pay this bill.Recipient
: A person who is physically able to receive a letter, parcel or delivery. This person must be "contactable" to play this role. That is, they must have a v:adr and v:n and optionally other information so that the delivery can be physically routed to them.
External
Roles defined by the context of your interaction. E.g. an eCommerce website "imposes" an eCommerce role on you, whereas a gaming site imposes broading a gaming role on you.
- subClassOf
Role
Defined instances:
Ecommerce
: A role imposed by eCommerce interactions, e.g. with an eCommerce websiteGaming
: A role imposed by gaming-related interactions, e.g. with a gaming website like world of warcraftSocialNetworking
: A role imposed by social interactions, e.g. with a social networking site
RootContext
A singleton context that contains the "root" Persona node of the Persona graph.
- subClassOf
h:Context
ProfileContext
- subClassOf
h:Context
A context that stores the following kinds of attributes:
- One or more Persona nodes each with RP-specific attributes
- e.g. united.com frequent flyer number and account balance
-
foaf:OnlineAccount
instance (including p:password)
- Persona nodes that have
p:source
attributes - Disclosure events
- Events that record the dateTime and the ids of the context(s) whose values have been disclosed to the RP.
MappingContext
A special context that doesn't contain any entities (other than the context singleton itself). However it does contain one or more classes that define mapping rules to/from PDM 2.0.
- subClassOf
h:Context
Attributes
eyeColor
- domain:
Persona
- value:
xsd:string
oneOf(green, blue, brown)
hasAgent
A person other than the user to whom some authority to act on the user's behalf has been delegated.
- domain:
p:Persona
- value:
p:Persona
issuer
In the Higgins Data Model 2.0 all Context attributes are optional. However in the Persona Data Model 2.0 we have this requirement:
- All contexts that are made available by a third party (e.g. the government, a bank, etc.) MUST have a
p:issuer
attribute - The attribute value is a URI
- The URI is either the domain name that is the authority behind the attribute assertions or
- The value
http://!self
- the user has explicitly asserted entities & attributes in this context - The value
http://!derived
- the active client has derived entities & attributes in this context based on observed behavior and/or assertions made by the user in other contexts
neverRememberPassword
Remember whether or not the person wants password managers to capture the password entered into a login form. Only used in Profile Contexts.
- domain:
p:Persona
- value:
xsd:boolean
password
The value of the password that a person might enter into a login form. Only used in Profile Contexts
- domain:
foaf:OnlineAccount
- value:
xsd:string
role
A role played by a Persona
- domain:
Persona
- value:
Role
source
Persona node in another context that describes an aspect (usually a role-specific aspect). Both personas may or may not be representations of the same person.
- domain:
p:Persona
- value:
p:Persona
consumer
Inverse of p:source
link.
- domain:
p:Persona
- value:
p:Persona
- consumer
subCorrelation
A relation between two Personas in different contexts that are asserted to be representing the same person and such that the value entity is used in a broader scope (with generally more relaxed access control policies). The size of the intended "audience" for the value entity is larger than the intended audience for the source entity.
- domain:
Persona
- value:
Persona
Vocabularies Imported by persona.owl
Higgins-Defined
- event: event types. Source is in svn: event.owl
- mapping: schema mapping rules. Source in svn: mapping.owl
- pay: payment methods. Source in svn: payment.owl
- app-data: app-data context definition. Source in svn: app-data.owl
- r-card: relationship card. See R-Card. Source in svn rcard.owl
- i-card: information card represented in OWL. See I-Card. Source in svn: icard.owl
- h: Higgins Data Model 2.0. Source in svn: higgins.owl
External
- v = vCard
- geo = WGS84 Geo Positioning
- foaf = Friend Of A Friend ontology
- skos = SKOS ontology
- spl = SPL, spin = SPIN, sp = SP
- dc = Dublin Core
- owl = OWL 2, RDFS, RDF
vCard
Persona imports vCard, uses most of it as is, but with a few tweaks described below.
UML Overview
We show below the aspect of PDM that builds on the vCard ontology. The heart of the PDM model is the p:Persona class. Concepts from vCard are shown in italics. Item in non-italics are defined in persona.owl discussed further on.
Classes
Note: Additional attributes from persona.owl are shown in bold below.
v:Address
- p:addressNote *
- p:start ..1
- p:end ..1
- v:address ..1
- v:extended-address ..1
- v:post-office-box ..1
- v:locality ..1
- v:region ..1
- v:postal-code ..1
- v:country-name ..1
v:Name
- v:honorific-prefix ..1
- v:given-name ..1
- v:additional-name *
- v:family-name ..1
- v:honorific-suffix ..1
v:Organization
- v:organization-name ..1
- v:organization-unit ..1
Other attributes
- v:logo
- v:tel
Other vCard classes
- v:Label (disjoint with v:Tel) - not used (don't yet understand what it is)
- v:Tel - not used; we use foaf:phone instead
Attributes
The following attributes are not used:
- v:street-address - we use the more granular p:street, p:houseName, p:houseNumber, p:apartment instead
- v:category
- v:class
- v:email - we use foaf:mbox instead
- v:fn
- v:agent - we use hasAgent instead
- v:geo - we use geo:location instead
- v:key
- v:mailer - not sure what this is
- v:photo - we use foaf:thumbnail instead
- v:prodid
- v:rev
- v:sort-string
- v:sound
- v:tz - not sure syntax of range/value
- v:uid - we use entityId instead
- v:url - we use foaf:page (and sub-attributes) instead
FOAF
Persona.owl imports FOAF and uses some of the classes and attributes it defines.
UML Overview
We show below the aspect of PDM that builds on the FOAF ontology:
Classes
- foaf:OnlineAccount
- foaf:OnlineEcommerceAccount
- foaf:OnlineGamingAccount
- foaf:OnlineChatAccount
- foaf:Document
- foaf:PersonalProfileDocument
- foaf:Image
Attributes
- foaf:account
- foaf:accountName
- foaf:status
- foaf:myersBriggs
- foaf:geekcode
- foaf:geekcode
- foaf:aimChatID
- foaf:skypeId
- foaf:skypID
- foaf icqChatID
- foaf:yahooID
- foaf:msnChatID
- foaf:made
- foaf:maker
- foaf:mbox
- foaf:mbox_sha1sum
- foaf:depicts
- foaf:depiction
- foaf:knows
- foaf:gender
- foaf:thumbnail
- foaf:page
- foaf:homepage
- foaf:weblog
- foaf:openid
- foaf:tipjar
- foaf:schoolHomepage
- foaf:workplaceHomepage
- foaf:workInfoHomepage
WSG84
Persona.owl imports WGS84 and uses some of its classes and attributes.
UML Overview
We show below the aspect of PDM that builds on the geospatial ontology:
Classes
- geo:Point
- geo:SpatialThing (a p:Persona is a subclass of geo:SpatialThing)
Attributes
SKOS
Persona.owl imports the SKOS ontology and uses a few of its classes and attributes.
Classes
- skos:Concept
Attributes
- skos:concept
- skos:broader
Concept Scheme (instance)
Persona.owl includes a concept hierarchy defined using SKOS. This hierarchy can be used by visual editors (e.g. a persona editor) to help organize the UI. Attributes defined in persona.owl include skos:concept
annotations to indicate the category of concept the attribute belongs to.
Which is represented as:
Note: see Higgins Data Model 2.0 for more information on concept schemes.
event.owl
A vocabulary to describe events that happen at a specific date and time and that affect either a specific attribute of an entity or all attributes of that entity. Event types include CRUD operations. A "Verfication" event type is also included.
Overview
Classes
event:Event
Change event. Abstract superclass. Subclasses describes changes to an attribute "attribute" of some entity "entity" that happened at dateTime "at"
- 1..1 event:at
- 1..N event:entity
event:AttributeChanged
A class of events wherein a single attribute is changed
- subClassOf event:Event
- 1..1 event:attribute
- 1..1 event:entity
event:Add
New value "value"(s) was/were added to attribute "attribute" of entity "entity" at dateTime "at"
- subClassOf event:AttributeChanged
- 1..N event:value - "new" value(s)
event:Delete
One, more or all values of attribute "attribute" of entity "entity" was deleted at dateTime "at". Values to be deleted are specified by one or more "oldValue"(s). If all values of attribute "attribute" are to be deleted then the oldValue (attribute) is omitted.
- subClassOf event:AttributeChanged
- 1..N event:oldValue
event:Get
One or more values of attribute "attribute" of entity "entity" was read at dateTime "at"
- subClassOf event:AttributeChanged
event:Modify
The attribute "attribute" of entity "entity" was modified at datetime "at". The value "oldValue" was replaced with value(s) "newValue"
- subClassOf event:AttributeChanged
- 1..1 event:oldValue
- 1..N event:value
event:Disclosure
A disclosure of attributes to an external party (e.g. an RP website). Each "entity" points to a context object (h:Context instance)
- subClassOf: event:Event
- 1..N entity (each entity is an instance of h:Context)
event:Verification
Verification event performed by the p:issuer of this context. If event:attribute is not present then event:entity(ies) in their entirety have been verified. Else if event:attribute is present then just the attribute mentioned has been verified.
- subClassOf event:Event
- 1..1 entity
- 0..1 verificationResult
Attributes
event:attribute
The entity that has been verified
- domain: event:Event
- value: an attribute
event:entity
The entity that has been verified
- domain: event:Event
- value: an entity
event:event
An event that happened. Used to associate event(s) with some object to which it relates (often an h:Context)
- value: event:Verification
event:at
When this event happened
- domain: Event
- value: dateTime
event:oldValue
Old value of an attribute
- domain: Delete, Modify
- value: entity or literal
event:value
New value(s)
- domain: Add, Modify
- value: entity or literal
event:verificationResult
Result of verification New value(s)
- domain: Verification
- value: one of {"false" , "indeterminate" , "true"}
mapping.owl
@@@TODO
payment.owl
Overview
Classes
PaymentMethod
Method of payment including credit cards, paypal, etc.
ByBankTransferInAdvance
, Cash
, CheckInAdvance
, COD
- subclassOf:
PaymentMethod
CreditCard
- subclassOf:
PaymentMethod
- 1..1
ccCid
- 1..1
ccExpiration
- 1..1
ccNumber
AMEX
, DinersClub
, Discover
, MasterCard
, VISA
, DirectDebit
, PayPal
- subclassOf:
CreditCard
Attributes
ccCid
- domain:
CreditCard
- value:
xsd:string
ccExpiration
- domain:
CreditCard
- value:
xsd:date
ccNumber
- domain:
CreditCard
- value:
xsd:string
paymentMethod
- domain:
Persona
- value:
PaymentMethod
icard.owl
Information Card (aka i-card) technology is defined by the OASIS IMI TC. It is a standard way to represent a person's digital identities using a card metaphor, XML card formats, and associated SOAP and HTTP network protocols. See also I-Card.
Before we introduce the I-Card classes, remember that in CDM multiple inheritance is allowed: any single entity may be a member of multiple classes simultaneously.
UML Overview
Classes
I-Card
Abstract class
- subclassOf:
h:Context
. - 1..1
cardId (xsd:string)
- a unique identifier for the card - 1..1
image
- an image bitmap for the background of the card when it is displayed - ... others.
P-Card
An OASIS IMI Personal card
- subclassOf:
I-Card
M-Card
An OASIS IMI Managed card
- subclassOf:
I-Card
P-Card Attributes
The attributes that define a personal card are taken directly from the OASIS IMI specification. An example p-card is shown here:
ERRATA: context object entity id should be _ContextSingleton
M-Card Attributes
Shown below is an example of an instance of an m-card. For simplicity this m-card has only a single supported claim, "LastName". The entity shown in the center of the card is a cache of what is returned by the STS in response to a request for a display token.
Note: There is an error in the above diagram the DisplayTokenEntity should have been modeled in the Persona data model (thus identity:surname would have been transformed into its equivalent in PDM.
Card Axioms
- For any M-Card: The value of any of the above "supported" claims attributes is considered to be a cache of the most recent value of these claims as fetched from the m-card's STS
rcard.owl
Vocabulary to describe R-Cards (including App-Cards).
UML Overview
Classes
R-Card
A Higgins relationship card (R-Card), which is essentially a profile of an IMI managed or personal i-card.
- subClassOf
i-card:I-Card
- 1..1
resource-udr
AppCard
An App-Card is an r-card that supports a Javascript app. It's resource-udr is a reference to a target entity in an AppData context (see app-data.owl). This resource-udr's target entity and its surrounding context are described by the app-data ontology.
- subClassOf: R-Card
- 0..1 template (URL) - a link to an external "template" context
Attributes
resource-udr
Representation of the http://schemas.informationcard.net/@ics/resource-udr/2009-03 claim type.
- domain:
R-Card
- value:
xsd:anyURI
- UDI resource reference
template
URL of an RDF file in n3 notation that describes the AppData context that should be instantiated for this AppCard. This file needs to have (i) the context attributes (although not persona attributes) from an AppData context (ii) the list "approved" attributes (within the overall vocabulary/schema) such as is listed in a MappingContext (iii) access control rules to indicate which attributes are user-editable (the balance being editable by the issuer/authority) and (iv) the type of context implementation (so we know which context provider to use).
- domain:
AppCard
- value:
xsd:anyURI
Personal R-Card Example
From a structural point of view, the presence of the resource-udr claim on a P-Card or an M-Card makes it be considered an R-Card. Here is an example of a personal R-Card:
ERRATA: the above image is incorrect for PDM 2.0. As above the card is a context. The entity (in this case referenced by the value of the resource_udr claim) would be a free standing Persona
entity (as above) and described in the PDM 1.1 model. Also icf: prefix should be removed along with ...2008... suffix. Also entityid of context object should be _ContextSingleton
Managed R-Card
The final type of card is the managed r-card. The presence of the resource-udr claim makes an ordinary M-Card into an R-Card. Here is an example of a managed R-Card:
ERRATA: The image above needs to be replaced. Card entityid should be _ContextSingleton
app-data.owl
Provides the classes and attributes to represent the "target" entity pointed to by an app-card, as well as this entity's surrounding context.
Classes
AppData
A kind of h:Context used to store the information about an app. This information is "pointed" to by an app-card (ako r-card)
- subClassOf: h:Context
- 1..1
appId
- 1..1
appDescription
- 1..1
appVersion
- 0..N
appSites
- 0..N
appEntityParam
- 0..1
appParams
- 1..1
appAdminURL
- 1..1
appServiceType
- the type of service from which the Javascript is fetched - 1..1
appService
- the Javascript service URL
AppParams
An AppParams instance is the value of an AppCard's appParams
attribute. It is a set of attributes and values used to initialize the app. Note: these attribute/values are combined with those derived from the AppCard's appEntityParam
.
AppData Attributes
appId
Uniquely identifies the app within the "developerId" (i.e. the card issuer) namespace. In other words the combination of the devID
and the appId
is globally unique. When using Kynetx KNS this is the ruleID with special constraint that this ruleID is globally unique.
- domain:
AppData
- value: string
appDescription
A human readable description of the app. Note: If appServer == http(s)://init.kobj.net, then the KNS "describe" API can be used by a context provider implementation to provide this attribute value.
- domain:
AppData
- value: string
appEntityParam
The name of an attribute (e.g. p:postal-code
) of the "target" entity of the app-card. The value of this named attribute of the target entity is used as a parameter to the app-card's app.
- domain:
AppData
- value: URI
appAdminURL
The URL of a webapp to load into an active client's "dashboard" (admin) UI.
- domain:
AppData
- value: xsd:anyURI
appEntityParam
The value is the (URI) name of an attribute on the AppCard's target entity. This referenced attribute and its value should be used to initialize the app.
- domain:
AppData
- value: URI name of an attribute
appParams
A set of attributes used to initialize the app.
- domain:
AppData
- value: AppParams
appService
The URI giving the endpoint from which the Javascript should be fetched.
- domain: Fetched
- value: URI
appServiceType
If value is "kynetx" then the browser extension that will inject the Javascript for this app-card should construct a Kynetx-compatible <script> block and call an initialization URL based on the value of the appService
attribute.
- domain: Fetched
- value: string whose value is oneof ("kynetx", "higgins").
appVersion
A human readable version of the app. Note: If appServer == http(s)://init.kobj.net, then the Kynetx KNS "describe" API can be used by a context Provider implementation to provide this attribute value.
- domain:
AppData
- value: string
Embedded AppData Attributes
appJS
The Javascript of the app. There must either be an appJS or an appService attribute and apptype (but not both)
- domain: Embedded
- value: base64encoded block of Javascript
Other Attributes
appEnabled
- domain is the target entity to which the underlying r-card's resource-udr points. If true the Javascript of this card is enabled to run.
- value: boolean
Example AppCard and AppData
Note: Not shown is a r-card:resource-udr link from the AppCard in the upper diagram to the Persona_1 entity in the lower diagram.
AppCard
Example of an AppCard context:
Note: missing from the above diagram is the list of supported claims. This list would include the ICF's resource-udr claim type.
AppData
Example of an AppData context:
Shown above is an example Embedded AppData context (shown as _ContextSingleton above). Within this context is an entity, Persona_1. The CreditBureauAppData object has a number of attributes described above.
Of particular interest is the app-card:appParams attribute whose value is the AppParams_1 object. The AppParams_1 in turn has two app initialization attributes, randomAttribute1 and 2.
The above example also shows an example of a event:Verification that happened in 1969. Presumably the entire contents of the context were shared with the credit bureau and the Work_1 address was attempted to be verified with a result of "failed."
Note: Since "appEnabled" = true attribute/value is not present on Persona_1 its value is assumed to be false and the card is thus disabled at present.
Restrictions on CDM 2.0 EntityIds
The PDM 2.0 uses a restricted set of the full capabilities of CDM 2.0. The restriction is in the area of EntityIds. PDM 2.0 adds the following constraints:
All entities:
- All entityIds MUST be URIs
- All entityId values MUST be Linked Data URIs or XRI 2.0 URIs
- All entityIds within a given context MUST be either (a) relative to a "base" URI of the context or (b) absolute
- Whether or not an entityID is relative or absolute MUST be able to be determined by inspection of its syntax
- Absolute entityIds MAY be globally resolvable
- Globally resolvable entityIds resolve to an entity (resource description) within exactly one context
Context objects:
- The entityId of the context object singleton is "_ContextSingleton"
See Also
- Persona Attribute List - a list of all of the attribute concepts that can be represented in PDM
- [1] - a developer summary of AppCard implementation issues
Use cases: