For 2.0M2 we plan the following structure:
- Connections (home page)
- All About Me - cross-connection view of all of the user's data
- Settings - Login/out, preferences, etc.
This page shows:
- A list of connections that you have (e.g. to websites)
- There's an "Add Connection" button/link to the "Add Connections" page
Add Connections Page
This page shows a list of connections that you can add.
The list is populated by retrieving a list of all "connection"-type templates (see ConnectionTemplate in Template vocabulary) minus any connections that the user already has. The proxy:domain attribute of the ConnectionTemplate identifies the connection that the template describes.
When you click on one the add connection wizard begins.
Add Connection Wizard
The following information allows the add connection wizard to display helpful information. Every ConnectionTemplate must have the following attributes:
- proxy:displayName (e.g. "New York Times")
- proxy:class (e.g. proxy:WebLogin)
- proxy:connectionType (e.g. "business")
- proxy:externalResource (e.g. "http://nytimes.com")
- proxy:domain (e.g. "nytimes.com")
It should also have:
- proxy:description (e.g. "A world class news site with all the news that's fit to print")
What the Add Connection Wizard does is dependent on the specific Connection Template Capabilities of the connection.
How is a connection represented?
A connection is represented as an instance of proxy:Connection (or subclass, usually proxy:WebLogin) that lives in the user's root context. See Proxy vocabulary for more about proxies. Each WebLogin has a proxy:domain attribute that indicates the domain of this connection. The proxy:domain value uniquely identifies this connection. If the user has a proxy for a domain (e.g. nytimes.com) then the user is considered to have a connection to nytimes.com.
All About Me
All about me is a page that displays all of the attributes of the user aggregated across all of their connection contexts.
Categories of attributes:
- Interested In
A small example
If we wanted to display the following attributes:
- email address used to log in to the PDS
- first name
- last name
We could use this view-builder structure:
Email, Address and Telephone Labels
The PDS data model has these three sources of data related to email, address and telephone labels:
- Observing what values the user has provided when asked questions within a specific "connection" context (i.e. the context of an interaction with an external website). For example if the user was asked for a "home" telephone number or a "work" email or a "shipping" address.
- Explicit action by the user to select one of the built-in labels (e.g. Mobile, Billing, Home etc.)
- Explicit action by the user to define & select a custom label (e.g. "iPhone")
Explicit actions (#2 or #3 above) override the observation (#1).
The algorithm to choose a label value to display is:
- If attribute (tel, email, adr) has user-defined "custom" label (p:label) then
- Display the custom label
- ElseIf it has a subclass of generic class (generic class is vcard:Tel, vcard:Internet, card:Address) then
- Display that class's skos:prefLabel
- Look at how the attribute has been used WRT p:Home and p:Work roles and force the label to be Work or Home (pick Home if it has been used in both Work and Home roles)
The first 3 below are new vcard:Internet subclasses defined in the Persona vocabulary. The last is the value of a p:label attribute also from the Persona vocabulary.
The first 4 below are modeled as a subset of standard vcard:Address subclasses (e.g. vcard:Home). The fifth is a new vcard:Address subclass defined in the Persona vocabulary. The last is the value of a p:label attribute also from the Persona vocabulary.
The first 5 below are modeled as vcard:Tel subclasses. The last is the value of a p:label attribute from the Persona vocabulary.