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.
Difference between revisions of "Form Filling"
(→Step 2) |
(→Step 4) |
||
(136 intermediate revisions by the same user not shown) | |||
Line 5: | Line 5: | ||
# Alice points her browser at staples.com and proceeds to try to buy a stapler. She eventually arrives at a checkout page | # Alice points her browser at staples.com and proceeds to try to buy a stapler. She eventually arrives at a checkout page | ||
# Alice fills in the form and submits it | # Alice fills in the form and submits it | ||
− | # Active client builds | + | # Active client builds context data structures from what it has observed |
# Alice points her browser at bestbuy.com and proceeds to buy a new CD | # Alice points her browser at bestbuy.com and proceeds to buy a new CD | ||
− | # Active client attempts to assist Alice in filling the form from | + | # Active client attempts to assist Alice in filling the form from data captured during her visit to staples.com |
# Alice edits/corrects form elements and submits it | # Alice edits/corrects form elements and submits it | ||
# Active client builds persona structures from what it has observed | # Active client builds persona structures from what it has observed | ||
Line 13: | Line 13: | ||
==Data structures at start== | ==Data structures at start== | ||
− | + | At the start only the root context shown here exists: | |
− | + | ||
− | + | ||
− | + | :_ContextSingleton | |
+ | rdf:type persona:RootContext . | ||
+ | |||
+ | :RootMe | ||
+ | rdf:type persona:Persona . | ||
==Step 1== | ==Step 1== | ||
Line 24: | Line 26: | ||
[[Image:Staples.com checkout.png|center]] | [[Image:Staples.com checkout.png|center]] | ||
− | The form filling Javascript will make a getExAttributes() call into the PDS Client API (of the active client) passing (among other parameters) the above form's submit URL | + | The form filling Javascript will make a getExAttributes() call into the PDS Client API (of the active client) passing (among other parameters) the above form's submit URL. |
− | + | This causes the PDS Client to | |
+ | * Find and load the mapping context whose name matches the domain of the site (e.g. staples.com) and find within it the AttributeMap (formerly HTMLForm) subclass whose name matches the normalized form submit URL. For example the staples.com ontology includes a subclass that has the mapping rules to map staples-specific HTML form elements into the PDM. | ||
+ | * Determine the "source" contexts necessary to satisfy the mapping rules. Note: most mapping rules use "generic" roles (e.g. "Recipient") while some may use the "local" role --that means that a ProfileContext of whose name (contextId) matches the website should be used. These "local" rules have the effect of storing site-specific information (account un/pw, local frequent flyer data). | ||
+ | * if there is ambiguity (@@@@ explain) then either getSuggestions() or the selector UI may be used to disambiguate (@@@@ elaborate) | ||
− | === | + | === Root Context === |
− | + | ||
− | + | The root context is unchanged. | |
+ | === Staples.com mapping context === | ||
− | + | We assume that the staple.com mapping context exists and is loaded. In addition to the _ContextSingleton it defines a subclass of AttributeMap (formerly HTMLForm) called "Office-supplies-StaplesCheckoutFlow": | |
+ | |||
+ | [[Image:Staples-com mapping v2.png|center]] | ||
+ | |||
+ | Errata | ||
+ | * The string "HTMLForm" above should be "AttributeMap" | ||
+ | * The string "persona:MappingContext" should be "mapping:MappingContext" | ||
+ | |||
+ | Notes | ||
+ | |||
+ | #The "Office-supplies-StaplescheckoutFlow" class name should be named "Staples.com-office-supplies-StaplesCheckoutFlow"<br> | ||
+ | #The spin:rule attributes of the Staples.com-office-supplies-StaplesCheckoutFlow class have been omitted above. | ||
== Step 2 == | == Step 2 == | ||
− | Alice fills in the form and submits it | + | Step 2: Alice fills in the form and submits it |
== Step 3 == | == Step 3 == | ||
− | |||
− | The Form Filler calls setAttributes() and records the values Alice entered. These data are mapped into the PDM by mapping rules defined by the staples.com | + | The Form Filler program calls setAttributes() and records the values Alice entered. These data are mapped into the PDM by mapping rules defined by the staples.com mapping context described above. The net result is the creation of: |
+ | * an RP-specific context of type p:ProfileContext | ||
+ | * a context containing a p:Persona of p:role value p:Recipient | ||
+ | * a context containing a p:Persona of p:role value p:Buyer | ||
+ | |||
+ | In addition the main persona in the profile context has one p:source link to the persona of role p:Recipient and another p:source link to the persona of role p:Buyer | ||
+ | |||
+ | ===3a Root Context=== | ||
+ | |||
+ | The RootMe gains: | ||
+ | * a p:subCorrelation link pointing to the "Persona_1" node in the new ProfileContext | ||
+ | * a p:subCorrelation link pointing to the "Persona_1" node in the new context containing the p:Recipient persona | ||
+ | * a p:subCorrelation link pointing to the "Persona_1" node in the new context containing the p:Buyer persona | ||
+ | |||
+ | And thus becomes: | ||
+ | |||
+ | :RootMe | ||
+ | a p:Persona ; | ||
+ | p:profileSubCorrelation recipient:Persona_1 , buyer:Persona_1 , alice-staples:Persona_1 . | ||
+ | |||
+ | ===3b Alice's Staples.com ProfileContext=== | ||
+ | |||
+ | This context holds Alice-specific RP-specific attributes. After this step 3 it contains: | ||
+ | |||
+ | :Persona_1 | ||
+ | a p:Persona ; | ||
+ | p:source recipient:Persona_1 , buyer:Persona_1 . | ||
+ | |||
+ | :_ContextSingleton | ||
+ | rdf:type p:ProfileContext . | ||
+ | |||
+ | ===3c "buyer" context=== | ||
+ | |||
+ | The buyer context is generated by the form filler's call to setAttributes(). The setAttributes() method consumes the mapping rules from the MappingContext. After all of the rules have been used the result is shown below. Note that the context singleton is marked as having and issuer of value "http://azigo.com/form-filler" and the main persona it contains as having a p:source link count (p:sourceLinkCount) value of 1. | ||
+ | |||
+ | :Address_1 | ||
+ | rdf:type vcard:Address ; | ||
+ | rdfs:label "Address_1"^^xsd:string ; | ||
+ | vcard:extended-address | ||
+ | "Suite 1000"^^xsd:string ; | ||
+ | vcard:locality "Peoria"^^xsd:string ; | ||
+ | vcard:postal-code "61604"^^xsd:string ; | ||
+ | vcard:region "IL"^^xsd:string ; | ||
+ | vcard:street-address | ||
+ | "123 S Main Street"^^xsd:string . | ||
+ | |||
+ | :Name_1 | ||
+ | rdf:type vcard:Name ; | ||
+ | vcard:family-name "Jones"^^xsd:string ; | ||
+ | vcard:given-name "Alice"^^xsd:string . | ||
+ | |||
+ | :Persona_1 | ||
+ | rdf:type p:Persona ; | ||
+ | p:role p:Ecommerce , p:Buyer ; | ||
+ | p:consumer aliceatstaples:Persona_1 ; | ||
+ | vcard:adr :Address_1 ; | ||
+ | vcard:n :Name_1 ; | ||
+ | vcard:tel :Voice_1 . | ||
+ | |||
+ | :Voice_1 | ||
+ | rdf:type vcard:Voice ; | ||
+ | rdf:value "tel:+358-555-1234567" . | ||
+ | |||
+ | :_ContextSingleton | ||
+ | rdf:type h:Context ; | ||
+ | p:issuer "http://azigo.com/form-filler"^^xsd:anyURI . | ||
+ | |||
+ | Or visually: | ||
+ | |||
+ | [[Image:Buyer ttfs.png|center]] | ||
+ | |||
+ | Errata: | ||
+ | * the above diagram should not have sourceLinkCount and should have a p:consumer link | ||
+ | |||
+ | ===3d "recipient" context=== | ||
+ | |||
+ | The recipient context is generated by the form filler's call to setAttributes(). The setAttributes() method consumes the mapping rules from the MappingContext. After all of the rules have been used the result is shown below. Note that the context singleton is marked as having and issuer of value "http://azigo.com/form-filler". | ||
+ | |||
+ | :Address_1 | ||
+ | rdf:type v:Address ; | ||
+ | v:locality "Wellesley Hills"^^xsd:string ; | ||
+ | v:postal-code "02481"^^xsd:string ; | ||
+ | v:region "MA"^^xsd:string ; | ||
+ | v:street-address "30 Washington Street"^^xsd:string . | ||
+ | |||
+ | :Name_1 | ||
+ | rdf:type v:Name ; | ||
+ | v:family-name "Jones"^^xsd:string ; | ||
+ | v:given-name "Alice"^^xsd:string . | ||
+ | |||
+ | :Persona_1 | ||
+ | rdf:type p:Persona ; | ||
+ | p:role p:Ecommerce , p:Recipient ; | ||
+ | p:consumer aliceatstaples:Persona_1 ; | ||
+ | v:adr :Address_1 ; | ||
+ | v:n :Name_1 ; | ||
+ | v:tel :Tel_1 . | ||
+ | |||
+ | :Tel_1 | ||
+ | rdf:type v:Tel ; | ||
+ | p:password "tel:+358-555-1234567"^^xsd:string . | ||
+ | |||
+ | :_ContextSingleton | ||
+ | rdf:type h:Context ; | ||
+ | p:issuer "http://azigo.com/form-filler"^^xsd:anyURI . | ||
+ | |||
+ | === 3e Record Disclosure === | ||
+ | |||
+ | To be written | ||
+ | |||
+ | == Step 4: Alice goes to BestBuy == | ||
+ | |||
+ | Alice points her browser at bestbuy.com and proceeds to buy a new CD. | ||
+ | |||
+ | == Step 5 == | ||
+ | |||
+ | Active client attempts to assist Alice in filling the form from data captured during her visit to staples.com | ||
+ | |||
+ | When Alice reaches the checkout page, the Form Filler program attempts to auto-fill the checkout data. It does so by calling getExAttributes(). The PDS Client implementation of getExAttributes() then does the following: | ||
+ | |||
+ | ===5a Load the bestbuy.com MappingContext=== | ||
+ | |||
+ | Fetches the context whose contextId is algorithmically derived from "bestbuy.com" (the RP parameter from getExAttributes()) from the PDS service. | ||
+ | |||
+ | ===5b Determines the set of required source contexts/personas=== | ||
+ | |||
+ | We examine the mapping rule for each of the attributes requested in getExAttributes. Each rule and its associated parameters provides matching criteria to find one or more suitable source contexts. | ||
+ | |||
+ | Different mapping rules have different parameters. Let's consider the mapping rule ''rolePathLiteral''. It has the following parameters: | ||
+ | * '''Role''' parameter. | ||
+ | ** Role of "p:Ecommerce". Determined by looking up the external role value of Persona node in the bestbuy.com Mapping Context | ||
+ | ** Role of "p:Buyer" | ||
+ | * '''Path''' parameter matches "vcard:adr" | ||
+ | * '''Literal''' parameter matches "vcard:street-address". | ||
+ | |||
+ | In this example rule, we'd search downwards from the RootMe persona for a persona that has a p:Role value of "Ecommerce" and a p:Role value of "Buyer". Which of course would match the following persona instance in the "buyer" context above: | ||
+ | |||
+ | :Persona_1 | ||
+ | persona:role persona:Ecommerce, persona:Buyer ; | ||
+ | |||
+ | Of course other mapping rules might select other source contexts. | ||
+ | |||
+ | There are also "local" matching rules. Rules wherein the role to match is set to a special value "!local". This kind of rule uses as its source a p:ProfileContext-type context whose contextId matches the domain of the RP (e.g. staples.com). | ||
+ | |||
+ | ===5c Create BestBuy Profile Context=== | ||
+ | |||
+ | The following bestbuy profile context would be created: | ||
+ | |||
+ | :Persona_1 | ||
+ | a p:Persona ; | ||
+ | p:source recipient:Persona_1 , buyer:Persona_1 . | ||
+ | |||
+ | :_ContextSingleton | ||
+ | rdf:type p:ProfileContext . | ||
+ | |||
+ | ===5d Return attribute values and record disclosure=== | ||
+ | |||
+ | If all rules haven an unambiguous source context then all rules can be evaluated and all values returned. On the other hand... | ||
+ | |||
+ | If more than one context matches as the source for a rule, then getExAttributes, being conservative, returns nil as the attribute value of that rule. The "client" app (e.g. the Javascript of an app-card) can either make a second call requesting values for attributes whose values had been returned as nil or (if it is a very privileged app) it can call the promiscuous getSuggestions() method for a single attribute and get back ALL of the possible values of that attribute. | ||
− | + | Just prior to returning attribute values getExAttributes() makes an audit entry for this disclosure of attributes. It adds a Disclosure-type event to the alice-staples.com ProfileContext. Here is the result: | |
− | + | ||
+ | :Disclosure_1 | ||
+ | rdf:type event:Disclosure ; | ||
+ | event:at "1979-01-01T00:00:15"^^xsd:dateTime ; | ||
+ | event:entity recipient:_ContextSingleton , :_ContextSingleton , buyer:_ContextSingleton . | ||
+ | |||
+ | :Persona_1 | ||
+ | rdf:type p:Persona . | ||
+ | |||
+ | :_ContextSingleton | ||
+ | rdf:type p:ProfileContext ; | ||
+ | event:event :Disclosure_1 . | ||
− | + | Visually: | |
− | + | [[Image:Disclosure 2.0.107.png|center]] |
Latest revision as of 10:18, 15 September 2010
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}Contents
Introduction
This document describes how the Persona Data Model 2.0 can be used to support a Javascript form filling application (app-card) making API calls into the PDS Client of an active client. We will illustrate by walking through the following scenario rom a cold start (i.e. a clean install of a browser-integrated active client):
- Alice points her browser at staples.com and proceeds to try to buy a stapler. She eventually arrives at a checkout page
- Alice fills in the form and submits it
- Active client builds context data structures from what it has observed
- Alice points her browser at bestbuy.com and proceeds to buy a new CD
- Active client attempts to assist Alice in filling the form from data captured during her visit to staples.com
- Alice edits/corrects form elements and submits it
- Active client builds persona structures from what it has observed
Data structures at start
At the start only the root context shown here exists:
:_ContextSingleton rdf:type persona:RootContext . :RootMe rdf:type persona:Persona .
Step 1
Alice eventually ends up at this form:
The form filling Javascript will make a getExAttributes() call into the PDS Client API (of the active client) passing (among other parameters) the above form's submit URL.
This causes the PDS Client to
- Find and load the mapping context whose name matches the domain of the site (e.g. staples.com) and find within it the AttributeMap (formerly HTMLForm) subclass whose name matches the normalized form submit URL. For example the staples.com ontology includes a subclass that has the mapping rules to map staples-specific HTML form elements into the PDM.
- Determine the "source" contexts necessary to satisfy the mapping rules. Note: most mapping rules use "generic" roles (e.g. "Recipient") while some may use the "local" role --that means that a ProfileContext of whose name (contextId) matches the website should be used. These "local" rules have the effect of storing site-specific information (account un/pw, local frequent flyer data).
- if there is ambiguity (@@@@ explain) then either getSuggestions() or the selector UI may be used to disambiguate (@@@@ elaborate)
Root Context
The root context is unchanged.
Staples.com mapping context
We assume that the staple.com mapping context exists and is loaded. In addition to the _ContextSingleton it defines a subclass of AttributeMap (formerly HTMLForm) called "Office-supplies-StaplesCheckoutFlow":
Errata
- The string "HTMLForm" above should be "AttributeMap"
- The string "persona:MappingContext" should be "mapping:MappingContext"
Notes
- The "Office-supplies-StaplescheckoutFlow" class name should be named "Staples.com-office-supplies-StaplesCheckoutFlow"
- The spin:rule attributes of the Staples.com-office-supplies-StaplesCheckoutFlow class have been omitted above.
Step 2
Step 2: Alice fills in the form and submits it
Step 3
The Form Filler program calls setAttributes() and records the values Alice entered. These data are mapped into the PDM by mapping rules defined by the staples.com mapping context described above. The net result is the creation of:
- an RP-specific context of type p:ProfileContext
- a context containing a p:Persona of p:role value p:Recipient
- a context containing a p:Persona of p:role value p:Buyer
In addition the main persona in the profile context has one p:source link to the persona of role p:Recipient and another p:source link to the persona of role p:Buyer
3a Root Context
The RootMe gains:
- a p:subCorrelation link pointing to the "Persona_1" node in the new ProfileContext
- a p:subCorrelation link pointing to the "Persona_1" node in the new context containing the p:Recipient persona
- a p:subCorrelation link pointing to the "Persona_1" node in the new context containing the p:Buyer persona
And thus becomes:
:RootMe a p:Persona ; p:profileSubCorrelation recipient:Persona_1 , buyer:Persona_1 , alice-staples:Persona_1 .
3b Alice's Staples.com ProfileContext
This context holds Alice-specific RP-specific attributes. After this step 3 it contains:
:Persona_1 a p:Persona ; p:source recipient:Persona_1 , buyer:Persona_1 . :_ContextSingleton rdf:type p:ProfileContext .
3c "buyer" context
The buyer context is generated by the form filler's call to setAttributes(). The setAttributes() method consumes the mapping rules from the MappingContext. After all of the rules have been used the result is shown below. Note that the context singleton is marked as having and issuer of value "http://azigo.com/form-filler" and the main persona it contains as having a p:source link count (p:sourceLinkCount) value of 1.
:Address_1 rdf:type vcard:Address ; rdfs:label "Address_1"^^xsd:string ; vcard:extended-address "Suite 1000"^^xsd:string ; vcard:locality "Peoria"^^xsd:string ; vcard:postal-code "61604"^^xsd:string ; vcard:region "IL"^^xsd:string ; vcard:street-address "123 S Main Street"^^xsd:string . :Name_1 rdf:type vcard:Name ; vcard:family-name "Jones"^^xsd:string ; vcard:given-name "Alice"^^xsd:string . :Persona_1 rdf:type p:Persona ; p:role p:Ecommerce , p:Buyer ; p:consumer aliceatstaples:Persona_1 ; vcard:adr :Address_1 ; vcard:n :Name_1 ; vcard:tel :Voice_1 . :Voice_1 rdf:type vcard:Voice ; rdf:value "tel:+358-555-1234567" . :_ContextSingleton rdf:type h:Context ; p:issuer "http://azigo.com/form-filler"^^xsd:anyURI .
Or visually:
Errata:
- the above diagram should not have sourceLinkCount and should have a p:consumer link
3d "recipient" context
The recipient context is generated by the form filler's call to setAttributes(). The setAttributes() method consumes the mapping rules from the MappingContext. After all of the rules have been used the result is shown below. Note that the context singleton is marked as having and issuer of value "http://azigo.com/form-filler".
:Address_1 rdf:type v:Address ; v:locality "Wellesley Hills"^^xsd:string ; v:postal-code "02481"^^xsd:string ; v:region "MA"^^xsd:string ; v:street-address "30 Washington Street"^^xsd:string . :Name_1 rdf:type v:Name ; v:family-name "Jones"^^xsd:string ; v:given-name "Alice"^^xsd:string . :Persona_1 rdf:type p:Persona ; p:role p:Ecommerce , p:Recipient ; p:consumer aliceatstaples:Persona_1 ; v:adr :Address_1 ; v:n :Name_1 ; v:tel :Tel_1 . :Tel_1 rdf:type v:Tel ; p:password "tel:+358-555-1234567"^^xsd:string . :_ContextSingleton rdf:type h:Context ; p:issuer "http://azigo.com/form-filler"^^xsd:anyURI .
3e Record Disclosure
To be written
Step 4: Alice goes to BestBuy
Alice points her browser at bestbuy.com and proceeds to buy a new CD.
Step 5
Active client attempts to assist Alice in filling the form from data captured during her visit to staples.com
When Alice reaches the checkout page, the Form Filler program attempts to auto-fill the checkout data. It does so by calling getExAttributes(). The PDS Client implementation of getExAttributes() then does the following:
5a Load the bestbuy.com MappingContext
Fetches the context whose contextId is algorithmically derived from "bestbuy.com" (the RP parameter from getExAttributes()) from the PDS service.
5b Determines the set of required source contexts/personas
We examine the mapping rule for each of the attributes requested in getExAttributes. Each rule and its associated parameters provides matching criteria to find one or more suitable source contexts.
Different mapping rules have different parameters. Let's consider the mapping rule rolePathLiteral. It has the following parameters:
- Role parameter.
- Role of "p:Ecommerce". Determined by looking up the external role value of Persona node in the bestbuy.com Mapping Context
- Role of "p:Buyer"
- Path parameter matches "vcard:adr"
- Literal parameter matches "vcard:street-address".
In this example rule, we'd search downwards from the RootMe persona for a persona that has a p:Role value of "Ecommerce" and a p:Role value of "Buyer". Which of course would match the following persona instance in the "buyer" context above:
:Persona_1 persona:role persona:Ecommerce, persona:Buyer ;
Of course other mapping rules might select other source contexts.
There are also "local" matching rules. Rules wherein the role to match is set to a special value "!local". This kind of rule uses as its source a p:ProfileContext-type context whose contextId matches the domain of the RP (e.g. staples.com).
5c Create BestBuy Profile Context
The following bestbuy profile context would be created:
:Persona_1 a p:Persona ; p:source recipient:Persona_1 , buyer:Persona_1 . :_ContextSingleton rdf:type p:ProfileContext .
5d Return attribute values and record disclosure
If all rules haven an unambiguous source context then all rules can be evaluated and all values returned. On the other hand...
If more than one context matches as the source for a rule, then getExAttributes, being conservative, returns nil as the attribute value of that rule. The "client" app (e.g. the Javascript of an app-card) can either make a second call requesting values for attributes whose values had been returned as nil or (if it is a very privileged app) it can call the promiscuous getSuggestions() method for a single attribute and get back ALL of the possible values of that attribute.
Just prior to returning attribute values getExAttributes() makes an audit entry for this disclosure of attributes. It adds a Disclosure-type event to the alice-staples.com ProfileContext. Here is the result:
:Disclosure_1 rdf:type event:Disclosure ; event:at "1979-01-01T00:00:15"^^xsd:dateTime ; event:entity recipient:_ContextSingleton , :_ContextSingleton , buyer:_ContextSingleton . :Persona_1 rdf:type p:Persona . :_ContextSingleton rdf:type p:ProfileContext ; event:event :Disclosure_1 .
Visually: