1.1 Background

This section is non-normative.

Microdata [ MICRODATA ] is a way of embedding data in HTML documents using attributes. The HTML DOM is extended to provide an API for accessing microdata information, and the microdata specification defines how to generate a JSON representation from microdata markup.

Mapping microdata to RDF 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 are disambiguated based on microdata item type ; an item with the type http://example.org/Cat can have both the property color and the property http://example.org/color , and these properties are semantically distinct under microdata. In RDF, all properties have IRIs.
• When an item has multiple properties with the same name, the values are always ordered; in RDF, property values are unordered unless they are explicitly listed in an RDF Collection . .
• A Except for some specific element values, a value in microdata is always a simple string which is interpreted by the consuming application. In RDF, values can be tagged with a datatype or 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 used to provide datatype and language information for RDF data, this would be contrary to the microdata specification.

Thus, in some places the needs of RDF consumers violate requirements of the microdata specification. This specification highlights where such violations occur and the reasons for them.

This specification 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 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. values .

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 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 (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 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 on a page, it wants to pull that microdata into the store on the fly.
• GoodRelations properties do not take rdf:List values; when they take multiple values they are unordered. The rdfs:range of a GoodRelations property indicates the datatype of the expected value, and GoodRelations processors will expect values to be cast to that type. Language information from the HTML needs to be captured as it is common that multiple values will be used to specify the same information in different languages.
• 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 GitHub Issue Tracker . These include the following:

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 specification with a base URI and fragment made up of the in-scope item type and item properties .
• Vocabulary-based URI generation, where the vocabulary is determined from the in-scope item type , either through an algorithmic modification of the type URL or by matching the URL against a registry . The vocabulary URI is then used to generate property URIs in a namespace parallel to the type URI.
• When there are multiple top-level item items 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/ns/md#item mapping at all.
• When an item has multiple values for a given property , place 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 name names s which are not absolute URL s, the propertyURI rule URLs , this section defines the algorithm for generating an absolute URL given an evaluation context including a current type , current name and current vocabulary .

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

Possible values for propertyURI are the following: contextual The contextual URI generation scheme guarantees that generated property URIs are unique based on the value of current name . This is required as the microdata data model requires that 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 first name n generates the URI 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 URI is used to create a 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 name names s that are not absolute URL URLs 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 MUST 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 ]).

The vocabulary URI prefix is made from the first itemtype value by stripping either the fragment content or last path segment , if the value has no fragment (See [ RFC3986 ]).

<div itemscope itemtype="http://example.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/ http://example.org/ . As there is no explicit propertyURI , the default vocabulary is used, and the The resulting property URI would be http://schema.org/title http://example.org/title .

<div itemscope>
<p itemscope itemprop='bar'>
  <span itemprop='baz'>Baz</span>
</p>
</div>

<rdf:Description xmlns:base="http://example/author#"
               rdf:type="http://microformats.org/profile/hcard">
<base:bar>
  <rdf:Description>
    <base:baz>Baz</base:baz>
  </rdf:Description>
</base:bar>
</rdf:Description>

3.3 3.2 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 dates, times Issue 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. Note durations
• If property URI generation was fixed to vocabulary , multiple values always generated both unordered data and ordered meter representations, elements provides doubles and there were datatype support, the registry could be reduced to a simple list of URLs without any further structure necessary. integers