Microdata to RDF

1.1 Background

This section is non-normative.

Microdata [ MICRODATA ] is a way of expressing metadata embedding data in HTML documents using attributes. A previous version of Microdata [[!MICRODATA]] included rules for generating RDF, but current Editor's Drafts have removed the explicit transformation procedure. Microdata The HTML DOM is now used as an API extended to access data from within provide an HTML DOM API for accessing microdata information, and as the microdata specification defines how to generate a JSON serialization. representation from microdata markup.

The original Mapping microdata to RDF transformation process created URIs enables consumers to merge data expressed in other RDF-based formats with microdata. It facilitates the use of RDF vocabularies within microdata, and enables microdata to be used with the full RDF toolchain. Some use cases for this mapping are described in Section 1.2 below.

Microdata's data model does not align neatly with RDF.

• Non-URL microdata properties that are expressed as non-absolute URIs. The algorithm was designed to create URIs which were distinct disambiguated based on microdata item type ; an item with the relationship between itemtype type http://example.org/Cat can have both the property color and itemprop contexts. This is required, as the Microdata data model requires that property http://example.org/color , and these properties maintain are semantically distinct semantic meanings in different contexts. However, this form of URI generation is typically different than that used within RDF vocabularies, where under microdata. In RDF, all properties typically have a common meaning within a given vocabulary . Microdata also specifies that items IRIs.
• When an item has multiple properties with the same name, the values are always ordered; in RDF, property values are ordered, unordered unless they are explicitly listed in an RDF Collection .
• A value in microdata is always a simple string which is not typically interpreted by the case for RDF vocabularies. consuming application. In fact, unless RDF, values can be tagged with a property has an rdfs:range of rdf:List , datatype or is unspecified, it may a language. According to the microdata specification, the HTML context of microdata markup should not change how microdata is interpreted, so although element names and HTML @lang attributes could be appropriate used to generate an RDF Collection . The Microdata JSON serialization does not retain provide datatype or and language information that might for RDF data, this would be derived from contrary to the HTML DOM. The microdata specification.

Thus, in some places the needs of RDF Transformation does retain both datatype consumers violate requirements of the microdata specification. This specification highlights where such violations occur and language information when it is available. the reasons for them.

This specification is an update to the original RDF transformation process in addition to allows for vocabulary -specific rules that affect the generation of property URIs and value serializations. This is facilitated by a registry that associates URIs with specific rules based on matching itemtype @itemtype values against registered URI prefixes do determine a vocabulary and potentially vocabulary-specific processing rules.

This specification also assumes that consumers of RDF generated from microdata may have to process the results in order to, for example, assign appropriate datatypes to property value s.

1.2 Use Cases

This section is non-normative.

During the period of the task force, a number of use cases were put forth for the use of Microdata microdata in generating RDF:

• Semantic search engines such as Sindice use RDF as their backend data model. They want to gather information expressed using microdata alongside information expressed in RDF-based formats and make it available to others to use, as a service. In these cases, the ultimate consumer, who will need to understand the vocabularies used within the microdata, is the program or person who pulls out data from Sindice. Sindice needs to retain the distinctions in the original Microdata microdata (e.g. ordering of items) and might not have built-in knowledge about the vocabulary of interest to the ultimate consumer. In this case, the ultimate consumer is likely to have to map/validate/handle errors in the data they get from Sindice.
• A consumer such as openelectiondata.org wants to support Microdata-based microdata-based markup of their vocabulary as well as RDFa-based markup, both going into an RDF-based data store. They want to use an off-the-shelf tool to extract the microdata. They want to configure the tool to give them the RDF that is appropriate for their known vocabulary . .
• A browser plugin that captures data for the user uses an RDF model as its backend store. Any time it encounters Microdata microdata on a page, it wants to pull that Microdata microdata into the store on the fly.
• GoodRelations require properties to be generated in a flat namespace, do not place take rdf:List values; when they take multiple values within a container. Ideally, a processor would make use of they are unordered. The rdfs:range declarations at parse time so properly typed literals could of a GoodRelations property indicates the datatype of the expected value, and GoodRelations processors will expect values to be constructed. It also requires cast to that plain literals retain language type. Language information in scope on from the HTML element, needs to be captured as it is common that multiple values will be used to specify the same information in different languages. Collection.
• Schema.org has an extension mechanism to allow authors to express information that is more detail than the pre-defined types, properties and enumerations. Property URIs are all in the same flat-namespace as types, but authors can add more detail by using a '/' after the type or property to provide more detail. For example, schema.org defines a musicGroupMember property having a URI of http://schema.org/musicGroupMember , and an author might express more detail through an ad-hoc sub-property musicGroupMember/leadVocalist , having the URI http://schema.org/musicGroupMember/leadVocalist .

1.3 Issues

This section is non-normative.

Decisions or open issues in the specification are tracked on the Task Force Issue Tracker . These include the following:

ISSUE 1

Vocabulary specific parsing for Microdata

ISSUE 2

Should Microdata-RDF generate XMLLiteral values values. This issue has been closed with no change as this would violate microdata's data model.

ISSUE 3

Should the registry allow property datatype specification.

ISSUE 4

Should the registry allow a name or URL to be used as an alias for @itemid .

The purpose of this specification is to provide input to a future working group that can make decisions about the need for a registry and the details of processing. Among the options investigated by the Task Force are the following:

• Property URI generation using the original Microdata microdata specification with a base URI and fragment made up of the in-scope itemtype item type and itemprop elements. properties .
• Vocabulary-based URI generation, where the vocabulary is determined from the in-scope itemtype , item type , either through an algorithmic modification of the type URI URL or by matching the URI URL against a registry . . The vocabulary URI is then used to generate property URIs in a namespace parallel to the type URI.
• Type-based URI generation, where the URI of the in-scope itemtype forms the base of property URI by adding the property to the type URI as a fragment. When there are multiple top-level items item s in a document, place items in an RDF Collection. Alternatively, simply list the items as multiple values, or do not generate an http://www.w3.org/1999/xhtml/microdata#item http://www.w3.org/ns/md#item mapping at all.
• When there are an item has multiple values for an itemprop , a given property , place items the values in an RDF Collection. Alternatively, do not use collections, use an alternative such as rdf:Seq , or place all values, whether or not multiple, into some form of collection.

3.1 Property URI Generation

This section is non-normative.

For property names name s which are not absolute URI URL s, the propertyURI rule defines the algorithm for generating an absolute URI URL given an evaluation context including an a current type , current name and current property . vocabulary .

The procedure for generating property URIs is defined in Generate Predicate URI .

Possible values for propertyURI are the following:

context contextual

The context contextual URI generation scheme guarantees that generated property URIs are unique for each current type and based on the value of current property combination. name . This is required as the Microdata microdata data model requires that property names name s are associated with specific items and do not have a global scope. (See Step 5 in Generate Predicate URI ).

URI creation uses a base URI with query parameters to indicate the in-scope type and name list. Consider the following example:

<span itemscope itemtype="http://microformats.org/profile/hcard">

  <span itemprop="n" itemscope>
    <span itemprop="given-name">
      Princeton
    </span>
  </span>
</span>

The type first name n generates the URI generation scheme appends http://www.w3.org/ns/md?type=http://microformats.org/profile/hcard?prop=n . However, the included name given-name is included in untyped item. The inherited property names that are not absolute URI s is used to current type using create a "#" separator. new property URI: http://www.w3.org/ns/md?type=http://microformats.org/profile/hcard?prop=n.given-name .

This scheme is compatible with the needs of other RDF serialization formats such as RDF/XML [ RDF-SYNTAX-GRAMMAR ], which rely on QNames for expressing properties. For example, the generated property URIs can be split as follows:

<rdf:Description xmlns:hcard="http://www.w3.org/ns/md?type=http://microformats.org/profile/hcard?prop="

                 rdf:type="http://microformats.org/profile/hcard">
  <hcard:n>
    <rdf:Description>
      <hcard:n.given-name>
        Princeton
      </hcard:n.given-name>
    </rdf:Description>
  </hcard:n>
</rdf:Description>

Looking at another example:

<div itemscope itemtype="http://schema.org/Person">

  <h2 itemprop="name">Jeni</h2>
</div>

This would generate http://www.w3.org/ns/md?type=http://schema.org/Person&prop=name .

vocabulary

The vocabulary URI generation scheme appends property names name s that are not absolute URI URL s to the URI prefix . . When generating property URIs, if the URI prefix does not end with a '/' or '#', a '#' is appended to the URI prefix . (See Step 4 in Generate Predicate URI .)

URI creation uses a base URL with query parameters to indicate the in-scope type and name list. Consider the following example:

<span itemscope itemtype="http://microformats.org/profile/hcard">

  <span itemprop="n" itemscope>
    <span itemprop="given-name">
      Princeton
    </span>
  </span>
</span>

Given the URI prefix http://microformats.org/profile/hcard , this would generate http://microformats.org/profile/hcard#n and http://microformats.org/profile/hcard#given-name . Note that the '#' is automatically added as a separator.

Looking at another example:

<div itemscope itemtype="http://schema.org/Person">

  <h2 itemprop="name">Jeni</h2>
</div>

Given the URI prefix http://schema.org/ , this would generate http://schema.org/name . Note that if the @itemtype were http://schema.org/Person/Teacher , this would generate the same property URI.

If the registry contains no match for current type implementations act as if there is a URI prefix made from the first @itemtype value by stripping either the fragment content or last path segment , if the value has no fragment (See [ RFC3986 ]).

Deconstructing the @itemtype URL to create or identify a vocabulary URI is a violation of the microdata specification which is necessary to support the use of existing vocabularies designed for use with RDF, and shared or inherited properties within all vocabularies.

The default value of propertyURI is context vocabulary .

<div itemscope itemtype="http://schema.org/Book">
  <h2 itemprop="title">Just a Geek</h2>
</div>

In this example, assuming no matching entry in the registry , the URI prefix is constructed by removing the last path segment , leaving the URI http://schema.org/ . As there is no explicit propertyURI , the default vocabulary is used, and the resulting property URI would be http://schema.org/title .

3.2 Value Ordering

This section is non-normative.

For items having multiple values for a property, given property , the multipleValues rule defines the algorithm for serializing these values. This is required as the Microdata data model requires that values be strictly ordered uses document order when generating property value s, as defined in Microdata DOM API as element.itemValue . However, many RDF vocabularies expect multiple values to be generated as triples sharing a common subject and predicate. In some cases, it may be useful to retain value ordering.

The procedure for generating property value s is defined in Generate Property Values .

Possible values for multipleValues are the following:

unordered

Values are serialized without ordering using a common subject and predicate. (See Step 7 in Generate Property Values ).

list

Multi-valued itemprop @itemprop s are serialized using an RDF Collection . . (See Step 8 in Generate Property Values ).

An example of how this might be specified in a registry is the following:

{

  "http://schema.org/": {
    "propertyURI":    "vocabulary",
    "multipleValues": "unordered"

  },
  "http://microformats.org/profile/hcard": {
    "propertyURI":    "type",
    "multipleValues": {"multipleValues": "list"}

  }
}

Additionally, some vocabularies may wish to specify this on a per-property basis. For example, within http://schema.org/MusicPlaylist the tracks property might depend on the order of values to to reproduce associated MusicRecording values.

{

 "http://schema.org/": {
   "propertyURI": "vocabulary",
   "multipleValues": "unordered",
   "properties": {
     "tracks": {"multipleValues": "list"}
   }
 }
}

The properties key takes a JSON Object as a value, which in turn has keys for each property that is to be given alternate semantics. Each name is implicitly expanded to it's URI representation as defined in Generate Predicate URI , so that the behavior is the same whether or not the name is listed as an absolute URL .

The default value of multipleValues is list unordered .

3.3 Value Typing

This section is non-normative.

In microdata, all values are strings. In RDF, values may be resources or may be typed with an appropriate datatype.

In some cases, the type of a microdata value can be determined from the element on which it is specified. In particular:

• URL property elements provide URLs
• time element provides dates and times

Using information about the content of the document where the microdata is marked up might be a violation of the spirit of the microdata specification, though it does not explicitly say in normative text that consumers cannot use other information from the HTML DOM to interpret microdata.

Additionally, one possible use of a registry would allow vocabularies to be marked with datatype information, so that a dc:time value, for example, would be understood to represent a literal with datatype xsd:date . This could be done by adding information for each property in the vocabulary requiring special treatment.

This might be represented using a syntax such as the following:

{

 "http://schema.org/": {
   "propertyURI": "vocabulary",
   "multipleValues": "unordered",
   "properties": {
     "dateCreated": {"datatype": "http://www.w3.org/2001/XMLSchema#date"}
   }
 }
}

The datatype identifies a URI to be used in constructing a typed literal .

In most cases, the relevant datatype for a value can be derived from knowledge of what property the value is for and the syntax of the value itself. Thus, values can be given datatypes in a post-processing step after the mapping of microdata to RDF described by this specification. However, where there is information in the HTML markup, such as knowledge of what element was used to mark up the value, which can help with determining its datatype, that information is used by this specification.

This concept is not explored further at this time, but could be developed further in a future revision of this document.