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.
Difference between revisions of "R-Card vocabulary"
(→AppCard) |
(→AppCard) |
||
| Line 74: | Line 74: | ||
==AppCard== | ==AppCard== | ||
| − | Every AppCard context must contain a h:Person entity. More precisely, it should contain a p:Person entity. The p:Person entity | + | Every AppCard context must contain a h:Person entity. More precisely, it should contain a p:Person entity. The p:Person entity is a node in the p:Person graph that is rooted at the RootMe p:Person node. |
| − | This p:Person node's purpose is to allow the context to be linked into the p:Person graph. It also | + | This p:Person node's purpose is to allow the context to be linked into the p:Person graph. It also serves as a cache of the value of the resource-udr claim (and other claims) returned in a token from the r-card's STS. This resource-udr is the link that points to main entity (probably a p:Person entity) in the card's associated AppData context. |
| − | + | NOTE: Since we don't yet support cards with proper STSes, a static resource-udr & value can be stored as a permanent attribute of the p:Person node. | |
| + | ===Example=== | ||
[[Image:App-card-example-v7.png|center]] | [[Image:App-card-example-v7.png|center]] | ||
Revision as of 23:19, 3 November 2010
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
Vocabulary to describe R-Cards (including App-Cards). Imported by Persona vocabulary.
Contents
Files
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
- 1..1
description
DynamicAppData
A kind of AppCard where its AppData context is dynamically created from the "recipe" of its "template" attribute:
- subClassOf: AppCard
- 0..1
template(URL) - a link to an external "template" context (See TemplateContext class in Template vocabulary)
StaticAppData
A kind of AppCard where its AppData context is specified by the value of its appDataContext attribute:
- subClassOf: AppCard
- 0..1
appDataContextContextID
Attributes
appDataContext
Context id of a pre-existing context
- domain:
StaticAppData - value:
h:Context- likely an AppData context instance
description
A string description of this AppCard
- domain:
AppCard - value: string
resource-udr
Representation of the http://schemas.informationcard.net/@ics/resource-udr/2009-03 claim type.
- domain:
h:Person- the h:Person node that represents the person this card is about - value:
xsd:anyURI- UDI resource reference
template
URL of an RDF file in n3 notation containing a serialization of a TemplateContext. This template context describes the kind of AppData context that should be dynamically instantiated for this AppCard (see the section on the "template.owl" vocabulary)
- domain:
DynamicAppData - 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 Person 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
AppCard
Every AppCard context must contain a h:Person entity. More precisely, it should contain a p:Person entity. The p:Person entity is a node in the p:Person graph that is rooted at the RootMe p:Person node.
This p:Person node's purpose is to allow the context to be linked into the p:Person graph. It also serves as a cache of the value of the resource-udr claim (and other claims) returned in a token from the r-card's STS. This resource-udr is the link that points to main entity (probably a p:Person entity) in the card's associated AppData context.
NOTE: Since we don't yet support cards with proper STSes, a static resource-udr & value can be stored as a permanent attribute of the p:Person node.
Example
Notes
- Missing from the above diagram is the list of supported claims. This list would include the ICF's resource-udr claim type.