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 "Flat Persona vocabulary"

(Attributes)
(Address)
 
(153 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}} [[Image:Higgins logo 76Wx100H.jpg|right]]  
 
{{#eclipseproject:technology.higgins|eclipse_custom_style.css}} [[Image:Higgins logo 76Wx100H.jpg|right]]  
  
A vocabulary that flattens (hides) some of the deep structure of [[Persona vocabulary]]. It imports [[Persona vocabulary]].
+
A vocabulary that flattens (hides) some of the deep structure of [[Persona vocabulary]].  Part of the [[Persona Data Model 2.0]]. It imports [[Persona vocabulary]], [[Mapping vocabulary]].
 +
 
  
 
===Files ===
 
===Files ===
* SVN source: [https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/ontology/org.eclipse.higgins.ontology/fp.owl fp.owl].
+
* SVN source: [https://dev.eclipse.org/svnroot/technology/org.eclipse.higgins/trunk/H2/org.eclipse.higgins.ontology/fp.n3 fp.n3].
 +
* Base URI: http://www.eclipse.org/higgins/ontologies/fp
  
 
== Introduction  ==
 
== Introduction  ==
  
Getting the whole world to commit to a single, rich ontology will never happen. So the next best thing is to define a rich, fine-grained internal ontology (as we have done in [[Persona Data Model 2.0]] (PDM)) and then define mapping rules between it an vocabularies that exist in the wild.  
+
The purpose of the [[Flat Persona vocabulary]] is to shield developers from having to understand the deeper structure of the PDM. For example, the developer simply chooses from this vocabulary the attribute they would like to get, and then calls one of the "getAttribute" APIs, passing this attribute. The getAttribute method sees that the attribute is in the flat persona namespace, looks up the associated rule, and uses this rule to traverse the PDM structure to retrieve the desired attribute value.  
  
We define mapping functions that ''get'' values of attributes in PDM object graphs. The inverse of these functions can ''set'' these values (although not all functions have inverse functions). One of the sub-parts of PDM is an ontology to describe these mapping functions. It is called mapping.owl and is described briefly on the main [[Persona Data Model 2.0|PDM]] page.  
+
Flat Persona vocabulary uses mapping functions that ''get'' values of attributes in PDM object graphs. The inverse of these functions can ''set'' these values (although not all functions have inverses). The [[Persona Data Model 2.0]] includes a vocabulary (see [[Mapping vocabulary]]), that defines these functions.  
  
The purpose of the [[Flat Persona vocabulary]] is to shield developers from having to understand the deeper structure of the PDM. For example, the developer simply chooses from this vocabulary which attribute they would like to get and then calls one of the "getAttribute" APIs passing this attribute. The getAttribute method, notices that the attribute is in the flat persona namespace, looks up the associated rule and uses this rule to traverse the PDM structure to retrieve the desired attribute value
+
=== Roles  ===
  
== Parameterization ==
+
To reduce somewhat the explosion of attributes in this namespace we parameterize the getAttribute APIs using a ''role[]'' parameter. This parameter contains one or more role strings as described below. Since a single natural person is represented in PDM as multiple p:Person entities (usually in different contexts), the role parameter is used to bias the selection of which source p:Person entities will be used to answer a getAttribute() query.
  
Since completely flattening out the attribute namespace would result in an explosion of attribute names, we parameterize using ''role'' and ''rp-role'' parameters.
+
==== ''Internal'' roles  ====
  
=== role ===
+
*Recipient - often called "shipping" (e.g. a "shipping address")
 +
*Home - attributes about the user's home life, (e.g. house where they live, or home telephone number)
 +
*Recipient, Home - a combination of the above
 +
*Work - information about the person's work life
 +
*Buyer - information about a person in their role as a buyer (e.g. a "billing" address)
 +
*DayTime - information about a person that is relevant during the day time (e.g. a daytime phone number)
  
We introduce a ''role'' parameter. Defined values are:
+
==== ''External'' roles  ====
  
* Recipient - often called "shipping" (e.g. a "shipping address")
+
The get attribute APIs can also be passed ''external'' role values to add sensitivity to the interaction context.  
* Home - attributes about the user's home life, (e.g. house where they live, or home telephone number)
+
* Recipient, Home - a combination of the above
+
* Work - information about the person's work life
+
* Buyer - information about a person in their role as a buyer (e.g. a "billing" address)
+
* DayTime - information about a person that is relevant during the day time (e.g. a daytime phone number)
+
  
=== rp-role ===
+
Depending on the interaction context one "source" p:Person entity might be more appropriate than another. For example if the context was a virtual world like Second Life, the person's given name is almost always not their "real world" given name. Person entities may carry one or more "role" tags that indicate appropriateness/use in one of these overall contexts. (We're using the word context generically here, we are not referring to Higgins Contexts).
  
Mapping rules are used within what we call an rp-role context. Since a single person is represented in PDM as multiple p:Person nodes (facets) when trying to map "given-name" we need to understand the broad, overall context of the interaction. Depending on the context a person might answer differently. For example if the context was a virtual world like Second Life, the person's given name is almost always not their "real world" given name. Persona nodes in PDM carry a number of "role" tags that indicate appropriateness/use in one of these overall contexts. (We're using the word context generically here, we are not referring to Higgins Contexts).
+
External role values include:  
  
We introduce a <rp-role> parameter. Defined values include:
+
*Ecommerce - an interaction within an eCommerce context  
* Ecommerce - an interaction within an eCommerce context  
+
*Gaming - an interaction with a gaming context  
* Gaming - an interaction with a gaming context
+
*SocialNetworking - an interaction within a social networking or chat context  
* SocialNetworking - an interaction within a social networking or chat context
+
*..other instances of class "External" (a subclass of "Role") within the [[Persona vocabulary]]
* ..other instances of class "External" (a subclass of "Role") within the [[Persona vocabulary]]
+
  
=== An Example: Given Name ===
+
==== Attribute URI parameter ====
  
In the flat persona vocabulary we define the attribute:
+
To specify one or more roles, we use the URI query parameter "r". For example to request a person's home telephone number we construct:
  
* <code>fp:givenName</code>
+
&nbsp; fp:phone?r=Home
  
The flat persona vocabulary associates this attribute with the following mapping rule:
+
== An Example: Given Name  ==
  
* <code>rolePathLiteral (role[], v:n, v:given-name) </code>
+
In the flat persona vocabulary we define the attribute <code>fp:givenName</code> as follows:
  
If the developer wanted to retrieve the value of the user's given name as that user would use in interactions with gaming websites they would call one of the getAttribute APIs passing the value of <code>fp:givenName?r=Gaming</code> where the "r" parameter's value specifies the ''Gaming'' rp-role.  
+
  fp:givenName
 +
      a      owl:DatatypeProperty ;
 +
      rdfs:domain fp:Person ;
 +
      fp:baseAttribute vcard:given-name .
  
The getAttribute method would invoke the <code>rolePathLiteral</code> function. This function traverses a path (or in rare cases a set of paths) through a PDM graph. Its name is a hint as to how it operates. This function takes three arguments (list-of-roles, v:n, v:given-name). It  starts at the root of the p:Person graph (i.e. the <code>RootMe</code> node) and searches breadth-first following <code>p:subCorrelation</code> links for the p:Person node that best matches the roles in the list-of-roles parameter and that has the required attribute.
+
The flat persona vocabulary associates this attribute with the mapping rule <code>rolePathLiteral (''role[], v:n, v:given-name'') </code> by including the following <code>map:nameRule</code> attribute of the <code>FlatPersonaPerson</code> class:
  
The <code>rolePathLiteral</code> function will start at the root RootMe node and breadth-first find the p:Person node whose role(s) best match the value(s) of ''role[]'' which in this case is the single value ''Gaming'' and that has a complex-valued attribute (aka link) of type <code>v:n</code> (from the vcard vocabulary). Further, it must have a simple-valued attribute of type <code>v:given-name</code>. The value of this literal attribute is the result of mapping the human concept of "given name."
+
  map:nameRule
 +
              [ a       map:rolePathLiteral ;
 +
                map:mappedAtt vcard:given-name ;
 +
                map:path vcard:n ;
 +
                map:predicate fp:givenName
 +
              ] ;
  
== Attributes ==
+
If the developer wanted to retrieve the value of the user's given name as that user would use in interactions with gaming websites they would call one of the getAttribute APIs passing the value of <code>fp:givenName</code> for the attribute desired parameter with an attached role value of ''Gaming (i.e. <code>fp:givenName?r=Gaming</code>).''
  
=== Account ===
+
The getAttribute method would invoke the <code>rolePathLiteral</code> function. This is determined by looking for a mapping rule whose <code>map:predicate</code> attribute is of value ":givenName" and taking the value of the <code>rdf:type</code> attribute (which is "map:rolePathLiteral" as shown above).
  
* foaf:accountName : pathLiteral (role[], foaf:account, foaf:accountName)
+
The rolePathLiteral function traverses a path (or in rare cases a set of paths) through a PDM graph. Its name is a hint as to how it operates. This particular function takes three arguments (role[], v:n, v:given-name). These arguments are (i) the value(s) of any role parameter(s) that are/were attached as URI query params (e.g. r=Gaming) on the attribute type URI passed in to the getAttribute method that called this rolePathLiteral function, (ii) the value of the <code>map:path</code> attribute in the rule body, and the value of the <code>map:mappAtt</code> attribute in the rule body. Note that different functions take different arguments.
* fp:accountPassword : pathLiteral (role[], foaf:account, p:password)
+
* fp:accountConfirmPassword : pathLiteral (role[], foaf:account, p:password)
+
  
=== Email ===
+
The rolePathLiteral function starts at the root of the p:Person graph (i.e. the <code>RootMe</code> node) and searches breadth-first following <code>h:correlation</code> links for the p:Person node that has the required attribute and best matches the roles in the role[] parameter.
* fp:email : literal (role[], foaf:mbox)
+
  
=== Names ===
+
In this case it would find the <code>p:Person</code> node that
 +
* has a complex-valued attribute (aka link) of type <code>v:n</code> (from the vcard vocabulary) whose value is the vcard:Address instance A1
 +
* has an A1 that has a simple-valued attribute of type <code>v:given-name</code>
 +
* (and in case there are multiple candidates) is the one whose role(s) best matches the value(s) of ''role[]'' (which in this case is the single value ''Gaming'')
 +
The value of this literal attribute is the result of mapping the concept of "given name."
  
*fp:honorificPrefix : pathLiteralInitial (role[], v:n, v:honorific-prefix)
+
== Attributes  ==
*fp:givenName : pathLiteral (role[], v:n, v:given-name)
+
*fp:additionalName : pathLiteral (role[], v:n, v:additional-name)
+
*fp:additionalName : pathLiteralInitial (role[], v:n, v:additional-name)
+
*fp:familyName : pathLiteral (role[], v:n, v:family-name)
+
*fp:honorificSuffix : pathLiteral (role[], v:n, v:honorific-suffix)
+
*fp:mothersMaidenName : literal (role[], p:mothersMaidenName)
+
*fp:familyNameAtBirth : pathLiteral (role[], v:n, p:familyNameAtBirth)
+
*fp:formattedName : TBD
+
  
=== Telephone Numbers ===
+
NOTE-1: this section of this wiki page contains an incomplete list of all of the fp attributes. Having to update this page manually is proving too tedious. What we really need to do is write a script that will auto-generate the contents of the rest of this wiki page section from the contents of the "fp.n3" file listed in the Files section above.
  
*fp:phone : pathRDFValue (roles[], v:tel)
+
NOTE-2: The fp.n3 file (see the Files section above) is incomplete. It does not contain an equivalent "fp" attribute for each of (presently nearly 300) attributes in the persona.owl vocabulary (and its imported sub-vocabularies). New attributes (and mapping rules, etc.) get added to fp.n3 as they are needed in practice.
*fp:mobilePhone : pathClassRDFValue ([roles[], v:tel, v:Cell)
+
  
=== Misc ===
+
=== Address  ===
* fp:relationshipStatus : literal (role[], osoc:relationshipStatus)
+
 
* fp:numberOfDependents : literal (role[], p:numberOfDependents)
+
*fp:streetAddress : rolePathLiteral (''role[], vcard:adr, vcard:street-address'')  
* fp:familyNameAtBirth : pathClassLiteral (role[], v:adr, p:Birth, v:family-name)
+
*fp:extendedAddress : rolePathLiteral (''role[], vcard:adr, vcard:extended-address'')
* fp:localityOfBirth : pathClassLiteral (role[], v:adr, p:Birth, v:locality)
+
*fp:careOf : rolePathLiteral (''role[], vcard:adr, p:careOf'')
* fp:countryOfBirth : pathClassLiteral (role[], v:adr, p:Birth, v:country)
+
*fp:postalCode : rolePathLiteral (''role[], vcard:adr, vcard:postal-code'')
* fp:passportNumber : pathClassLiteral (role[], idDoc, p:Passport, p:docNumber)
+
*fp:country : rolePathPathLiteral (''role[], vcard:adr, p:country, rdfs:label'')
* fp:currentEmployerName : currentEmployerName(role[])
+
*fp:locality : rolePathLiteral (''role[], vcard:adr, vcard:locality'')
* fp:bankSortCode : pathClassLiteral (role[], pay:paymentMethod, pay:DirectDebit, pay:bankSortCode)
+
*fp:region = rolePathPathLiteral (''role[], vcard:adr, p:region, rdfs:label'')
* fp:bankAccountNumber : pathClassLiteral (role[], pay:paymentMedhod, pay:DirectDebit, pay:bankSortCode)
+
*fp:4digitExtensionZip : TBD
* fp:timeAtCurrentEmployer
+
 
* fp:vehicleLicenseNumber : pathClassLiteral (role[], idDoc, p:VehicleLicense, p:docNumber)
+
*fp:singleLineAddress = roleSingleLineAddress (''role[]'')
* fp:nationalInsuranceNumber : literal (role[], p:nationalInsuranceNumber)
+
*fp:appartmentNumber : appartmentNumber (''role[]'') - extract from street-address and extended-address
 +
*fp:buildingName : buildingName (''role[]'') - extract from street-address and extended-address
 +
*fp:houseNumber : houseNumber (''role[]'') - extract from street-address and extended-address
 +
*fp:buildingNameOrNumber&nbsp;: buildingNameOrNumber (''role[]'') - extract from street-address and extended-address
 +
*fp:district : district (''role[]'') - extract from locality
 +
*fp:residentFrom : rolePathLiteral (''role[], vcard:adr, h:start'')
 +
*fp:residentFromDay : day (rolePathLiteral (''role[], vcard:adr, h:start''))
 +
*fp:residentFromMonth : month (rolePathLiteral (''role[], vcard:adr, h:start''))
 +
*fp:residentFromYear : year (rolePathLiteral (''role[], vcard:adr, h:start''))
 +
*fp:residentUntil : rolePathLiteral (''role[], vcard:adr, h:end'')
 +
*fp:residentUntilDay : day (rolePathLiteral (''role[], vcard:adr, h:end''))
 +
*fp:residentUntilMonth : month (rolePathLiteral (''role[], vcard:adr, h:end''))
 +
*fp:residentUntilYear : year (rolePathLiteral (''role[], vcard:adr, h:end''))
 +
 
 +
=== Birth  ===
 +
 
 +
*fp:localityOfBirth : rolePathClassLiteral (''role[], v:adr, p:Birth, v:locality'')  
 +
*fp:countryOfBirth : rolePathClassLiteral (''role[], v:adr, p:Birth, v:country'')  
 +
*fp:age : roleAge (''role[]'') - uses v:bday
 +
*fp:ageRange : roleLiteral(''role[]'', p:ageRange)
 +
*fp:dayOfBirth : rolePathLiteral(''role[], p:birthday, p:day)
 +
*fp:monthOfBirth : rolePathLiteral(''role[], p:birthday, p:month)
 +
*fp:yearOfBirth : rolePathLiteral(''role[], p:birthday, p:year)
 +
 
 +
=== Email  ===
 +
 
 +
*fp:email : rolePathLiteral (''role[], vcard:email, rdf:value'')
 +
 
 +
=== Financial  ===
 +
 
 +
*fp:bankSortCode : rolePathClassLiteral (''role[], pay:paymentMethod, pay:DirectDebit, pay:bankSortCode'')  
 +
*fp:bankAccountNumber : rolePathClassLiteral (''role[], pay:paymentMedhod, pay:DirectDebit, pay:bankSortCode'')
 +
 
 +
=== Geolocation  ===
 +
 
 +
*fp:latitude : rolePathLiteral2 (''role[], wgs:location, wgs:lat'')
 +
*fp:longitude : rolePathLiteral2 (''role[], wgs:location, wgs:long'')
 +
*fp:altitude : rolePathLiteral2 (''role[], wgs:location, wgs:alt'')
 +
 
 +
=== Identifiers  ===
 +
 
 +
*fp:passportNumber : rolePathClassLiteral (''role[], idDoc, p:Passport, p:docNumber'')  
 +
*fp:nationalInsuranceNumber : roleLiteral (''role[], p:nationalInsuranceNumber'')
 +
 
 +
=== Interest ===
 +
*fp:like : roleEntity (''role[], p:like'')
 +
*fp:favorite : roleEntity (''role[], p:favorite'')
 +
*fp:block : roleEntity (''role[], p:block'')
 +
 
 +
=== Misc  ===
 +
 
 +
*fp:picture : roleEntity (''role[], foaf:img'')
 +
 
 +
=== Name  ===
 +
 
 +
*fp:honorificPrefix : rolePathLiteral (''role[], v:n, v:honorific-prefix'')
 +
*fp:givenName : rolePathLiteral (''role[], v:n, v:given-name'')
 +
*fp:additionalName : rolePathLiteral (''role[], v:n, v:additional-name'')
 +
*fp:additionalNameInitial : rolePathLiteralInitial (''role[], v:n, v:additional-name'')
 +
*fp:familyName : rolePathLiteral (''role[], v:n, v:family-name'')
 +
*fp:honorificSuffix : rolePathLiteral (''role[], v:n, v:honorific-suffix'')
 +
*fp:mothersMaidenName : roleLiteral (''role[], p:mothersMaidenName'')
 +
*fp:familyNameAtBirth : rolePathLiteral (''role[], v:n, p:familyNameAtBirth'')
 +
*fp:formattedName : TBD
 +
*fp:title&nbsp;: rolePathLiteral(''role[], v:title'')
 +
 
 +
=== Payment  ===
 +
 
 +
*fp:paymentMethodType : rolePathPathLiteral (''role[], pay:paymentMethod, rdf:type, skos:prefLabel'')
 +
*fp:nameOnCard : rolePathClassLiteral (''role[], pay:paymentMethod, pay:CreditCard, pay:nameOnCard'')
 +
*fp:creditCardNumber : rolePathClassLiteral (''role[], pay:paymentMethod, pay:CreditCard, pay:ccNumber'')
 +
*fp:creditCardExpiration : rolePathClassLiteral (''role[], pay:paymentMethod, pay:CreditCard, pay:ccExpiration'')
 +
*fp:creditCardExpirationMonth : rolePathClassMonth (''role[], pay:paymentMethod, pay:CreditCard, pay:ccExpiration'')
 +
*fp:creditCardExpirationYear : rolePathClassYear (''role[], pay:paymentMethod, pay:CreditCard, pay:ccExpiration'')
 +
 
 +
=== Property  ===
 +
 
 +
*fp:vehicleLicenseNumber?country=c&amp;region=r : vehicleLicenseNumber (''role[], c, r'')
 +
 
 +
=== Relationships  ===
 +
 
 +
*fp:gender = roleDiscreteRangeString ('', p:gender, p:Gender'')
 +
*fp:relationshipStatus : roleLiteral (''role[], p:relationshipStatus'')
 +
*fp:numberOfDependents : roleLiteral (''role[], p:numberOfDependents'')
 +
 
 +
=== Telephone  ===
 +
 
 +
*fp:phone : rolePathEntity (''role[], vcard:tel, rdf:value'')
 +
*fp:mobilePhone : rolePathClassEntity (''role[], vcard:tel, vcard:Cell, rdf:value'')
 +
*fp:fax : rolePathClassEntity (''role[], vcard:tel, vcard:Fax, rdf:value'')
 +
 
 +
=== Work  ===
 +
 
 +
*fp:currentEmployerName : currentEmployerName (''role[]'')
 +
*fp:timeAtCurrentEmployer : timeAtCurrentEmployer (''role[]'')
  
 
== Links ==
 
== Links ==
 +
* [[Persona Data Model 2.0]]
 
* [[Persona vocabulary]]
 
* [[Persona vocabulary]]
* [[Persona Attribute List]]
+
** [[Persona vocabulary#Vocabularies_Imported_by_persona.owl]]
 +
* [[Mapping vocabulary]]
 +
 
 +
[[Category:Higgins 2 Vocabularies]]

Latest revision as of 09:47, 5 May 2012

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

A vocabulary that flattens (hides) some of the deep structure of Persona vocabulary. Part of the Persona Data Model 2.0. It imports Persona vocabulary, Mapping vocabulary.


Files

Introduction

The purpose of the Flat Persona vocabulary is to shield developers from having to understand the deeper structure of the PDM. For example, the developer simply chooses from this vocabulary the attribute they would like to get, and then calls one of the "getAttribute" APIs, passing this attribute. The getAttribute method sees that the attribute is in the flat persona namespace, looks up the associated rule, and uses this rule to traverse the PDM structure to retrieve the desired attribute value.

Flat Persona vocabulary uses mapping functions that get values of attributes in PDM object graphs. The inverse of these functions can set these values (although not all functions have inverses). The Persona Data Model 2.0 includes a vocabulary (see Mapping vocabulary), that defines these functions.

Roles

To reduce somewhat the explosion of attributes in this namespace we parameterize the getAttribute APIs using a role[] parameter. This parameter contains one or more role strings as described below. Since a single natural person is represented in PDM as multiple p:Person entities (usually in different contexts), the role parameter is used to bias the selection of which source p:Person entities will be used to answer a getAttribute() query.

Internal roles

  • Recipient - often called "shipping" (e.g. a "shipping address")
  • Home - attributes about the user's home life, (e.g. house where they live, or home telephone number)
  • Recipient, Home - a combination of the above
  • Work - information about the person's work life
  • Buyer - information about a person in their role as a buyer (e.g. a "billing" address)
  • DayTime - information about a person that is relevant during the day time (e.g. a daytime phone number)

External roles

The get attribute APIs can also be passed external role values to add sensitivity to the interaction context.

Depending on the interaction context one "source" p:Person entity might be more appropriate than another. For example if the context was a virtual world like Second Life, the person's given name is almost always not their "real world" given name. Person entities may carry one or more "role" tags that indicate appropriateness/use in one of these overall contexts. (We're using the word context generically here, we are not referring to Higgins Contexts).

External role values include:

  • Ecommerce - an interaction within an eCommerce context
  • Gaming - an interaction with a gaming context
  • SocialNetworking - an interaction within a social networking or chat context
  • ..other instances of class "External" (a subclass of "Role") within the Persona vocabulary

Attribute URI parameter

To specify one or more roles, we use the URI query parameter "r". For example to request a person's home telephone number we construct:

  fp:phone?r=Home

An Example: Given Name

In the flat persona vocabulary we define the attribute fp:givenName as follows:

 fp:givenName
     a       owl:DatatypeProperty ;
     rdfs:domain fp:Person ;
     fp:baseAttribute vcard:given-name .

The flat persona vocabulary associates this attribute with the mapping rule rolePathLiteral (role[], v:n, v:given-name) by including the following map:nameRule attribute of the FlatPersonaPerson class:

 map:nameRule
             [ a       map:rolePathLiteral ;
               map:mappedAtt vcard:given-name ;
               map:path vcard:n ;
               map:predicate fp:givenName
             ] ;

If the developer wanted to retrieve the value of the user's given name as that user would use in interactions with gaming websites they would call one of the getAttribute APIs passing the value of fp:givenName for the attribute desired parameter with an attached role value of Gaming (i.e. fp:givenName?r=Gaming).

The getAttribute method would invoke the rolePathLiteral function. This is determined by looking for a mapping rule whose map:predicate attribute is of value ":givenName" and taking the value of the rdf:type attribute (which is "map:rolePathLiteral" as shown above).

The rolePathLiteral function traverses a path (or in rare cases a set of paths) through a PDM graph. Its name is a hint as to how it operates. This particular function takes three arguments (role[], v:n, v:given-name). These arguments are (i) the value(s) of any role parameter(s) that are/were attached as URI query params (e.g. r=Gaming) on the attribute type URI passed in to the getAttribute method that called this rolePathLiteral function, (ii) the value of the map:path attribute in the rule body, and the value of the map:mappAtt attribute in the rule body. Note that different functions take different arguments.

The rolePathLiteral function starts at the root of the p:Person graph (i.e. the RootMe node) and searches breadth-first following h:correlation links for the p:Person node that has the required attribute and best matches the roles in the role[] parameter.

In this case it would find the p:Person node that

  • has a complex-valued attribute (aka link) of type v:n (from the vcard vocabulary) whose value is the vcard:Address instance A1
  • has an A1 that has a simple-valued attribute of type v:given-name
  • (and in case there are multiple candidates) is the one whose role(s) best matches the value(s) of role[] (which in this case is the single value Gaming)

The value of this literal attribute is the result of mapping the concept of "given name."

Attributes

NOTE-1: this section of this wiki page contains an incomplete list of all of the fp attributes. Having to update this page manually is proving too tedious. What we really need to do is write a script that will auto-generate the contents of the rest of this wiki page section from the contents of the "fp.n3" file listed in the Files section above.

NOTE-2: The fp.n3 file (see the Files section above) is incomplete. It does not contain an equivalent "fp" attribute for each of (presently nearly 300) attributes in the persona.owl vocabulary (and its imported sub-vocabularies). New attributes (and mapping rules, etc.) get added to fp.n3 as they are needed in practice.

Address

  • fp:streetAddress : rolePathLiteral (role[], vcard:adr, vcard:street-address)
  • fp:extendedAddress : rolePathLiteral (role[], vcard:adr, vcard:extended-address)
  • fp:careOf : rolePathLiteral (role[], vcard:adr, p:careOf)
  • fp:postalCode : rolePathLiteral (role[], vcard:adr, vcard:postal-code)
  • fp:country : rolePathPathLiteral (role[], vcard:adr, p:country, rdfs:label)
  • fp:locality : rolePathLiteral (role[], vcard:adr, vcard:locality)
  • fp:region = rolePathPathLiteral (role[], vcard:adr, p:region, rdfs:label)
  • fp:4digitExtensionZip : TBD
  • fp:singleLineAddress = roleSingleLineAddress (role[])
  • fp:appartmentNumber : appartmentNumber (role[]) - extract from street-address and extended-address
  • fp:buildingName : buildingName (role[]) - extract from street-address and extended-address
  • fp:houseNumber : houseNumber (role[]) - extract from street-address and extended-address
  • fp:buildingNameOrNumber : buildingNameOrNumber (role[]) - extract from street-address and extended-address
  • fp:district : district (role[]) - extract from locality
  • fp:residentFrom : rolePathLiteral (role[], vcard:adr, h:start)
  • fp:residentFromDay : day (rolePathLiteral (role[], vcard:adr, h:start))
  • fp:residentFromMonth : month (rolePathLiteral (role[], vcard:adr, h:start))
  • fp:residentFromYear : year (rolePathLiteral (role[], vcard:adr, h:start))
  • fp:residentUntil : rolePathLiteral (role[], vcard:adr, h:end)
  • fp:residentUntilDay : day (rolePathLiteral (role[], vcard:adr, h:end))
  • fp:residentUntilMonth : month (rolePathLiteral (role[], vcard:adr, h:end))
  • fp:residentUntilYear : year (rolePathLiteral (role[], vcard:adr, h:end))

Birth

  • fp:localityOfBirth : rolePathClassLiteral (role[], v:adr, p:Birth, v:locality)
  • fp:countryOfBirth : rolePathClassLiteral (role[], v:adr, p:Birth, v:country)
  • fp:age : roleAge (role[]) - uses v:bday
  • fp:ageRange : roleLiteral(role[], p:ageRange)
  • fp:dayOfBirth : rolePathLiteral(role[], p:birthday, p:day)
  • fp:monthOfBirth : rolePathLiteral(role[], p:birthday, p:month)
  • fp:yearOfBirth : rolePathLiteral(role[], p:birthday, p:year)

Email

  • fp:email : rolePathLiteral (role[], vcard:email, rdf:value)

Financial

  • fp:bankSortCode : rolePathClassLiteral (role[], pay:paymentMethod, pay:DirectDebit, pay:bankSortCode)
  • fp:bankAccountNumber : rolePathClassLiteral (role[], pay:paymentMedhod, pay:DirectDebit, pay:bankSortCode)

Geolocation

  • fp:latitude : rolePathLiteral2 (role[], wgs:location, wgs:lat)
  • fp:longitude : rolePathLiteral2 (role[], wgs:location, wgs:long)
  • fp:altitude : rolePathLiteral2 (role[], wgs:location, wgs:alt)

Identifiers

  • fp:passportNumber : rolePathClassLiteral (role[], idDoc, p:Passport, p:docNumber)
  • fp:nationalInsuranceNumber : roleLiteral (role[], p:nationalInsuranceNumber)

Interest

  • fp:like : roleEntity (role[], p:like)
  • fp:favorite : roleEntity (role[], p:favorite)
  • fp:block : roleEntity (role[], p:block)

Misc

  • fp:picture : roleEntity (role[], foaf:img)

Name

  • fp:honorificPrefix : rolePathLiteral (role[], v:n, v:honorific-prefix)
  • fp:givenName : rolePathLiteral (role[], v:n, v:given-name)
  • fp:additionalName : rolePathLiteral (role[], v:n, v:additional-name)
  • fp:additionalNameInitial : rolePathLiteralInitial (role[], v:n, v:additional-name)
  • fp:familyName : rolePathLiteral (role[], v:n, v:family-name)
  • fp:honorificSuffix : rolePathLiteral (role[], v:n, v:honorific-suffix)
  • fp:mothersMaidenName : roleLiteral (role[], p:mothersMaidenName)
  • fp:familyNameAtBirth : rolePathLiteral (role[], v:n, p:familyNameAtBirth)
  • fp:formattedName : TBD
  • fp:title : rolePathLiteral(role[], v:title)

Payment

  • fp:paymentMethodType : rolePathPathLiteral (role[], pay:paymentMethod, rdf:type, skos:prefLabel)
  • fp:nameOnCard : rolePathClassLiteral (role[], pay:paymentMethod, pay:CreditCard, pay:nameOnCard)
  • fp:creditCardNumber : rolePathClassLiteral (role[], pay:paymentMethod, pay:CreditCard, pay:ccNumber)
  • fp:creditCardExpiration : rolePathClassLiteral (role[], pay:paymentMethod, pay:CreditCard, pay:ccExpiration)
  • fp:creditCardExpirationMonth : rolePathClassMonth (role[], pay:paymentMethod, pay:CreditCard, pay:ccExpiration)
  • fp:creditCardExpirationYear : rolePathClassYear (role[], pay:paymentMethod, pay:CreditCard, pay:ccExpiration)

Property

  • fp:vehicleLicenseNumber?country=c&region=r : vehicleLicenseNumber (role[], c, r)

Relationships

  • fp:gender = roleDiscreteRangeString (, p:gender, p:Gender)
  • fp:relationshipStatus : roleLiteral (role[], p:relationshipStatus)
  • fp:numberOfDependents : roleLiteral (role[], p:numberOfDependents)

Telephone

  • fp:phone : rolePathEntity (role[], vcard:tel, rdf:value)
  • fp:mobilePhone : rolePathClassEntity (role[], vcard:tel, vcard:Cell, rdf:value)
  • fp:fax : rolePathClassEntity (role[], vcard:tel, vcard:Fax, rdf:value)

Work

  • fp:currentEmployerName : currentEmployerName (role[])
  • fp:timeAtCurrentEmployer : timeAtCurrentEmployer (role[])

Links

Back to the top