Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Form Filling"

("recipient" context)
("buyer" context)
Line 90: Line 90:
 
==="buyer" context===
 
==="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#staples.com" and the main persona it contains as having a p:source link count (p:sourceLinkCount) value of 1.
+
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
 
   :Address_1
Line 122: Line 122:
 
   :_ContextSingleton
 
   :_ContextSingleton
 
       rdf:type h:Context ;
 
       rdf:type h:Context ;
       p:issuer "http://azigo.com/form-filler#staples.com"^^xsd:anyURI .
+
       p:issuer "http://azigo.com/form-filler"^^xsd:anyURI .
  
 
Or visually:
 
Or visually:

Revision as of 10:10, 15 September 2010

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
Higgins logo 76Wx100H.jpg

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):

  1. Alice points her browser at staples.com and proceeds to try to buy a stapler. She eventually arrives at a checkout page
  2. Alice fills in the form and submits it
  3. Active client builds context data structures from what it has observed
  4. Alice points her browser at bestbuy.com and proceeds to buy a new CD
  5. Active client attempts to assist Alice in filling the form from data captured during her visit to staples.com
  6. Alice edits/corrects form elements and submits it
  7. 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:

Staples.com checkout.png

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":

Staples-com mapping v2.png

Errata

  • The string "HTMLForm" above should be "AttributeMap"
  • The string "persona:MappingContext" should be "mapping:MappingContext"

Notes

  1. The "Office-supplies-StaplescheckoutFlow" class name should be named "Staples.com-office-supplies-StaplesCheckoutFlow"
  2. 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

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 .

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 .

"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:sourceLinkCount 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:

Buyer ttfs.png

"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#staples.com" and the main persona it contains as having a p:source link count (p:sourceLinkCount) value of 1.

 :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#staples.com"^^xsd:anyURI .

Step 4

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:

(1) 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.

(2) 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).

(3) 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:

Disclosure 2.0.107.png

Back to the top