View source for WebIntents/schema.org Types

== Passing schema.org data through Web Intents ==

(for more background on schema.org, in particular for [http://www.w3.org/wiki/WebSchemas/SchemaDotOrgProposals new vocabulary proposals] under discussion, see the W3C [[WebSchemas]] group. New vocab to support Web Intents could be proposed there too...)

Web Intents types can be string literals, accepting any value. The recommendation is to use literals in the URL syntax, matching the microdata itemtype convention. This document specifies how that mapping works for types from schema.org, for example, http://schema.org/Person, http://schema.org/ImageObject, http://schema.org/MusicPlaylist.

Using string literal types causes Web Intents dispatch to match the types to services exactly. Thus a service which accepts http://schema.org/Thing will not be matched with an intent invoked by the client with a type of http://schema.org/Event, despite the types being hierarchical in the schema.org taxonomy.

When these types are used, the client must prepare the payload data field of the intent as a dictionary, with the keys specified in the corresponding schema.org type. For nested types, the values should again be dictionaries with keys corresponding to the defined type.

For example, an intent to follow a schema.org/Person entry can be constructed as follows:

 <nowiki>
var person = {};
person.name = "Greg";
person.url = "http://greg.example.com";
person.additionalName = "Joseph";
person.alumniOf = {"name":"Caltech", "url":"http://caltech.edu"};
person.address = {};
person.address.email = "greg@greg.example.com";
person.address.telephone = "555-1212";
person.addressCountry = {};
person.addressCountry.name = "US";
navigator.startActivity(new Intent(
{"action":"http://webintents.org/follow",
 "type":"http://schema.org/Person",
 "data":person}));</nowiki>

The fields in the person object follow those defined at http://schema.org/Person. All fields are optional. Nested types are defined according to the fields of the type defined in the parent specifier.

Lists of objects may also be passed. In this case, the type seen by the receiver will be a list instead of a dictionary. Services must discriminate this possibility. For example, an invocation with an intent to share a pair of images would be constructed as follows:

 <nowiki>
var image1 = {};
image1.url = "http://images.com/img1";
image1.name = "image 1";
var image2 = {
  "url" : "http://images.com/img2",
 "author" : { "name" : "Greg" },
 "dateCreated" : "2012-03-28T20:55Z" };
navigator.startActivity(new Intent(
{ "action":"http://webintents.org/share",
  "type":"http://schema.org/ImageObject",
  "data":[image1, image2]}));</nowiki>

On the receiving end, the service will do something like this:

 <nowiki>
if (intent.data instanceof Array) {
  // ...
}</nowiki>

to handle the case of being passed an array type. Services which return multiple schema.org values must prepare them in an array as well, for passing to intent.postResult. That looks like this:

 <nowiki>
intent.data.postResult([
  {"name":"Greg",
   "address":{"email":"greg@example.com"}},
  {"name":"Rachel",
    "address":{"email":"rachel@example.com"}}]);</nowiki>

In this case, the client will need logic like the above to detect a single result from a list of results.