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 "View-builder vocabulary"
(→Cascading Cardinality) |
(→Cascading Cardinality) |
||
| Line 90: | Line 90: | ||
The reality is that depending on the site-specific connection context where the attribute is used, the cardinality restrictions may be different. For example, in a connection context to a specific website, say, amazon.com, they may ask for an address but not require the country to be specified. In this case the view-builder-powered form might (based on the UI designer's preference) either (a) simply omit the country field or (b) include the country field but indicate that it is not required. | The reality is that depending on the site-specific connection context where the attribute is used, the cardinality restrictions may be different. For example, in a connection context to a specific website, say, amazon.com, they may ask for an address but not require the country to be specified. In this case the view-builder-powered form might (based on the UI designer's preference) either (a) simply omit the country field or (b) include the country field but indicate that it is not required. | ||
| − | Further, the cardinality may vary within a single context. A site might allow an attribute to be optional during one kind of interaction (e.g. subscribing to an email list), but require that same attribute in a different interaction (e.g. registering for an account, or at checkout). To support this we allow cardinality sub-class restrictions to be placed on the root ViewNode of a view-builder tree structure. These cardinality restrictions override any cardinality restrictions on the :Person class within the template which in turn overrides the cardinality restrictions | + | Further, the cardinality may vary within a single context. A site might allow an attribute to be optional during one kind of interaction (e.g. subscribing to an email list), but require that same attribute in a different interaction (e.g. registering for an account, or at checkout). To support this we allow cardinality sub-class restrictions to be placed on the root ViewNode of a view-builder tree structure. These cardinality restrictions override any cardinality restrictions on the :Person class within the template which in turn overrides the cardinality restrictions described above as "cascading". |
== Example == | == Example == | ||
Revision as of 00:48, 10 May 2012
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}} Vocabulary to describe a view of a context. A view is a tree structure of groups of attributes to be displayed/edited. Part of the Persona Data Model 2.0.
Contents
Files
- Most recently published
- SVN source: view-builder.n3
UML Overview
Classes
Group
A logical group of Slots and/or sub-Groups
- subClassOf: ViewNode
- 1..1 skos:prefLabel
- 1..N child
MultiGroup
Similar to a regular Group, a MultiGroup is parent for a set of child Slots. Different from a Group, it also has an view-builder:attribute attriubte. Another difference is that a MultiGroup self-replicates such that there end up being N instances of itself--one for each of the N values of its attribute attribute. Each of these N values is an instance of p:Person (p1, p2, ... pN). The view-builder:attribute attributes of its child Slot should be evaluated within the scope of its parent p:Person p1..pN.
It is used in view that need to display a set of N "credit cards" (really p:Person nodes with p:Buyer roles), or a set of N "addresses" (really p:Person nodes).
- subClassOf: Group
- 1..1 attribute
- 0..1 app-data:script
Slot
Metadata about how an attribute from the Persona vocabulary (or one of its imports) or from the Flat Persona vocabulary or from the rdf (e.g. rdf:class) should be presented.
- subClassOf: ViewNode
- 1..1 attribute
- 0..1 app-data:script
ViewNode
(Abstract) A node in the view hierarchy
- 1..1 displayOrder
- 0..1 layout
Attributes
attribute
The attribute that should be displayed in this Slot, or the attribute to evaluate when handling a MultiGroup.
- domain: Slot
- value: rdf:Property
child
A child of a Group
- domain: Group
- value: ViewNode
displayOrder
A number that indicates the relative position with respect to the displayOrder of sibling objects with this same attribute. Lower numbers indicate precedence.
- domain: Slot or Group
- value: xsd:Integer
layout
An optional URL of an html/javascript template sub-page of a web app.
- domain: ViewNode
- value: URI
script
After the user edits a slot, this script should be executed. (e.g. to push the updated value to an external website).
- domain: Slot
- value: app-data:Push
Displaying Groups
Each Group MUST have a skos:prefLabel that describes the internationalized string label for the group.
A Group is a logical collection of Slots (and sub-groups). It is entirely up to the look & feel of the UI to determine how this grouping (and sub-grouping) is represented.
There is a special kind of (non-top level) Group called a MultiGroup. Unlike regular Groups it has (like a Slot) a view-builder:attribute. As described in the MultiGroup class above, a MultiGroup is a pattern that describes how its child Slots should be collected together into N groups. N is the number of values of the MultiGroup's view-builder:attribute attribute. This attribute's values are always p:Person instances. Each of these p:Person instances acts as a source of attribute/values for one of these N groups.
MultiGroups are used to display a set of attributes (e.g. credit card number, name, address, phone, etc.) for each of N p:Person entities.
Cascading Metadata
Each Slot or MultiGroup holds an attribute A. In order to display the slot both the form and the value of A must be retrieved. The value might be a boolean, a string, etc. The form of A is described by attribute metadata (as described in Attribute Metadata and in Attribute Definitions) --a set of attributes about A. How to retrieve the value of A is out of the scope of this document. We are concerned here about how to retreive the form of A.
We have recently introduced a convention that the context id of metadata attribute M must be the same as the context id of A. If the currie form of A is ctxt:attname then the currie form of M must also have a prefix of ctxt. For example if the attribute is fp:postalCode then metadata statements about fp:postalCode must be in the Flat Persona vocabulary context (fp being a prefix for this vocabulary) along with the definition of fp:postalCode itself.
However...
In the case where A has an associated mapping rule (details: Mapping vocabulary) that maps it to attribute B, the situation is more complex. In this case metadata about A is the result of applying the metadata found about A (in its context as described above) as an override to metadata found about B. This is roughly analogous to how cascading stylesheets work in HTML CSS. Lastly, since B may in turn be mapped to C the overriding is recursive.
Cascading Cardinality
Each Slot or MultiGroup has a view-builder:attribute from one of a number of vocabularies (e.g. Persona vocabulary, Flat Persona vocabulary, or others). As with any attribute this attribute may be subject to owl:minCardinality and/or owl:maxCardinality restrictions placed on it by its "containing" class.
The reality is that depending on the site-specific connection context where the attribute is used, the cardinality restrictions may be different. For example, in a connection context to a specific website, say, amazon.com, they may ask for an address but not require the country to be specified. In this case the view-builder-powered form might (based on the UI designer's preference) either (a) simply omit the country field or (b) include the country field but indicate that it is not required.
Further, the cardinality may vary within a single context. A site might allow an attribute to be optional during one kind of interaction (e.g. subscribing to an email list), but require that same attribute in a different interaction (e.g. registering for an account, or at checkout). To support this we allow cardinality sub-class restrictions to be placed on the root ViewNode of a view-builder tree structure. These cardinality restrictions override any cardinality restrictions on the :Person class within the template which in turn overrides the cardinality restrictions described above as "cascading".
Example
Here is an example of a view-builder structure:
:AgeRange
rdf:type view:Slot ;
view:attribute fp:ageRange ;
view:displayOrder 1 .
:DemographicsGroup
rdf:type view:Group ;
view:child :PostalCode , :AgeRange , :Gender ;
view:displayOrder 1 ;
skos:prefLabel "Demographics"^^xsd:string .
:Gender
rdf:type view:Slot ;
view:attribute fp:gender ;
view:displayOrder 2 .
:Interest
rdf:type view:Slot ;
view:attribute p:like ;
view:displayOrder 1 .
:InterestsGroup
rdf:type view:Group ;
view:child :Interest ;
view:displayOrder 2 ;
skos:prefLabel "Interests"^^xsd:string .
:PostalCode
rdf:type view:Slot ;
view:attribute fp:postalCode ;
view:displayOrder 10 .
:ViewRoot
rdf:type view:Group ;
view:child :InterestsGroup , :DemographicsGroup ;
view:displayOrder 1 ;
skos:prefLabel "Advertising Profile"^^xsd:string .
The demographics group shown above has slots whose attributes, fp:gender, fp:ageRange, fp:postalCode, are all from the Flat Persona vocabulary.
The interests group shown above has a slot whose attribute is the complex valued attribute, online-behavior:interest. In this rather special case the presentation logic should render the name of the class of the instance (e.g. "Humor > Satire" or "World Destinations > Africa > East Africa > Nigeria") as opposed to rendering the value of an attribute of the instance as is done in the usual case.
A few additional notes on the above example
The FlatPersona namespace is only useful when either (a) there are not multiple entity values of the same attribute being requested, or, (b) there are just a few alternative entities and the "right" one can be figured out by matching using the role tags (e.g. "home" vCard entity vs. "work" vCard entity). Flattening, a simplification. It is an attempt to hide some complexity. But there are times when we can't hide the complexity. Multiple non-role-tagged entity values of an attribute is one of those times.
Displaying the "interests" of a user is a case where the flat persona approach won't work because a single p:Person node has a multi-valued (multi-entity-valued) "p:like" attribute. You'll notice in the view hierarchy under the interests Group there is a Slot whose view:attribute attribute whose value is p:like--a value that is from the persona vocabulary and NOT from the flat persona vocabulary. We have to get all of the values of this attribute. These values are (multiple) int:InterestTopic-class entities. The specific class of this InterestTopic might be "Satire", but of course we probably want to display something like "Humor > Satire" --in other words rendering not just the "leaf" class name but where it sits in relation to the (up to 6 levels) of super-classes ("Humor" being the super-class of "Satire" in this case).