View source for HTML Data Improvements

This page holds drafts and other tracking for improvements to microdata and RDFa developed by the [[Html-data-tf|HTML Data TF]].

* [http://www.w3.org/Bugs/Public/buglist.cgi?product=HTML+WG&component=HTML+Microdata+%28editor%3A+Ian+Hickson%29 Microdata bugs in W3C Bugzilla]
* [http://www.w3.org/Bugs/Public/buglist.cgi?product=HTML+WG&component=HTML%2BRDFa+%28editor%3A+Manu+Sporny%29 HTML+RDFa bugs in W3C Bugzilla]
* [http://www.w3.org/2010/02/rdfa/track/products/2 tracker on RDFa 1.1 Core]

== Raised Bugs ==

The following bugs have been raised with appropriate working groups.

=== Additional XSD Datatypes ===

HTML5's <code>time</code> elements supports timezones and weeks as well as the usual date/time/duration datatypes. These new datatypes will be hard to map into RDF or XML. This has been raised with the XML Schema Working Group (see [http://www.w3.org/Bugs/Public/show_bug.cgi?id=14881 bug 14881]) but it's likely that they will reject the bug for lack of time and that W3C Notes will be required to define new <code>xs:timezone</code> and <code>xs:yearWeek</code> types to support this data.

=== Link Relations ===

This is background information and examples for [http://www.w3.org/2010/02/rdfa/track/issues/108 RDFA-ISSUE-108].

According to RDFa Core, if someone uses an recognised term within a <code>@rel</code> attribute then an RDFa processor will interpret that term based on the [http://www.w3.org/2010/02/rdfa/drafts/2011/ED-rdfa-core-20111020/#T-local-term-mappings local term mappings]. If the term isn't recognised, it will be interpreted based on the [http://www.w3.org/2010/02/rdfa/drafts/2011/ED-rdfa-core-20111020/#T-local-default-vocabulary local default vocabulary]. In HTML+RDFa 1.1, the local term mappings are based on the [http://www.w3.org/2011/rdfa-context/html-rdfa-1.1.html IANA link relations] and the local default vocabulary is undefined. Unrecognised terms are therefore ignored in HTML+RDFa unless the <code>@vocab</code> attribute is used to provide a local default vocabulary.

According to HTML5, there are a set of [http://dev.w3.org/html5/spec/links.html#linkTypes built-in link types] with specified (and complex) semantics which is then extended using the [http://microformats.org/wiki/existing-rel-values#HTML5_link_type_extensions microformats wiki] as a [http://dev.w3.org/html5/spec/links.html#other-link-types registry].

There are also microformats, in particular [http://gmpg.org/xfn/ XFN], which rely on the <code>@rel</code> attribute. XFN looks for any relations within its [http://gmpg.org/xfn/11 known list] and interprets these as pointers from the author of the document in which they are found to people with whom that author has a relationship.

There are problems with this state of affairs in that documents may be interpreted differently when they are processed with an RDFa processor from when they are processed with an HTML5 processor.

==== 1. Different registries ====

The set of link relationships recognised by RDFa is different from that recognised by HTML. Some HTML link relations will be mapped into properties by RDFa, and some not; some relations recognised by RDFa will be ignored by HTML processors and some not. Publishers need to look at different lists to know what link relations are available.

==== 2. Combined link relations ====

RDFa breaks up the value of the <code>@rel</code> attribute on spaces and simply considers each term that results individually. HTML5 combines <code>alternate</code> and <code>stylesheet</code> to provide a single meaning ("alternate stylesheet"). However, under RDFa processing, a document containing:

 <nowiki><link rel="alternate stylesheet" href="/styles/mobile.css" title="Mobile"></nowiki>

will create the triples:

 <nowiki><>
  xhv:alternate </styles/mobile.css> ;
  xhv:stylesheet </styles/mobile.css> ;
  .</nowiki>

when this is not the intention of the author or the meaning understood by an HTML processor.

The link relation <code>shortcut icon</code> is similarly treated specially by HTML processors (as a synonym for just <code>icon</code>).

==== 3. Non-document link relations ====

The <code>bookmark</code> HTML link relation specifies a relationship between the nearest ancestor section of the page and the linked resource. Assuming no other RDFa markup within the page, an RDFa processor will erroneously associate the bookmark with the HTML document as a whole instead.

The example from the spec is:

 <nowiki><body>
 <h1>Example of permalinks</h1>
 <div id="a">
  <h2>First example</h2>
  <p><a href="a.html" rel="bookmark">This</a> permalink applies to
  only the content from the first H2 to the second H2. The DIV isn't
  exactly that section, but it roughly corresponds to it.</p>
 </div>
 <h2>Second example</h2>
 <article id="b">
  <p><a href="b.html" rel="bookmark">This</a> permalink applies to
  the outer ARTICLE element (which could be, e.g., a blog post).</p>
  <article id="c">
   <p><a href="c.html" rel="bookmark">This</a> permalink applies to
   the inner ARTICLE element (which could be, e.g., a blog comment).</p>
  </article>
 </article>
</body></nowiki>

This will create the triples:

 <nowiki><>
  xhv:bookmark <a.html> ;
  xhv:bookmark <b.html> ;
  xhv:bookmark <c.html> ;
  .</nowiki>

which is not the intention of the document. The intention is more like:

 <nowiki><#a> xhv:bookmark <a.html> .
<#b> xhv:bookmark <b.html> .
<#c> xhv:bookmark <c.html> .</nowiki>


==== 4. Alias link relations ====

Some link relations are aliases for others. For example, <code>copyright</code> is an alias for <code>license</code> &mdash; it means the same thing and should be treated in the same way by HTML processors. However, an RDFa processor will not normalise to the standard term.

In addition, alias link relations are not valid within HTML documents. If they are not recognised as terms by RDFa processing and a publisher were to use them (coupled with <code>@vocab</code> such that they did not have a prefix) then they would be creating an invalid HTML document.

==== 5. Misinterpretation due to @vocab ====

When there is a local default vocabulary indicated by a <code>@vocab</code> attribute, and the term is not listed in the set that is recognised by RDFa, RDFa will interpret a link relation based on that vocabulary, while HTML and microformats semantics will not be affected. For example, say that <code>security.example.org</code> had a vocabulary for security disclosures about vulnerabilities in operating systems, and the RDFa in the page looked like:

 <nowiki><a vocab="http://security.example.org/"
   rel="disclosure" href="/vulnerability/4389">...</a></nowiki>

An RDFa 1.1 processor will interpret this as:

 <nowiki><> <http://security.example.org/disclosure> </vulnerability/4389> .</nowiki>

whereas based on the extended list of link relations managed by the microformats wiki, an HTML processor will assume that the link is to a "list of patent disclosures or a particular patent disclosure itself made with respect to material for which such relation type is specified".

Similarly, if the publisher had actually meant to use the HTML definition of the link relation, they might not realise that the in-scope <code>@vocab</code> attribute actually changes the meaning of the normal link relation for RDFa processors in a way that they didn't intend.

There are also clashes with microformat link relations. For example:

  <nowiki><a vocab="http://purl.org/dc/terms/"
   rel="date" resource="http://reference.data.gov.uk/id/day/2011-11-15">15th November 2011</a></nowiki>

will result in a <code>dc:date</code> relationship under RDFa processing, but as a link to someone the author of the page is dating according to XFN.

This arises due to the mismatch between the RDFa and HTML sets of link relations, so is a side-effect of the problem of working from different lists of link relations; if all HTML and microformats link relations were reserved, there wouldn't be a problem, but if only a subset are reserved, the above becomes a problem.

==== 6. Misinterpretation due to RDFa context ====

The subject of link relations will often be different under RDFa and HTML processing. The subject of the HTML link relationships is usually (but not always) the document, whereas the subject of a property in RDFa is determined through the <code>@about</code>, <code>@typeof</code> etc attributes. An example is:

 <nowiki><figure about="picture.jpg">
  <img src="picture.jpg">
  <figcaption><a rel="license"
    href="http://creativecommons.org/licenses/by-nc-nd/3.0/">CC-by-nc-nd</a></figcaption>
</figure></nowiki>

In this case, an RDFa processor will associate the license with the image (<code>picture.jpg</code>) whereas an HTML processor will associate the license with the HTML page.

== Potential Bugs ==

The following haven't been raised as bugs, but might be.

=== Structured Values ===

Unlike microformats and RDFa, microdata doesn't have any support for values that are HTML structures. This has previously been [http://www.w3.org/Bugs/Public/show_bug.cgi?id=13468 raised as a bug] which was resolved without change.

There are examples in the [http://schema.org/WebPage schema.org documentation] which use HTML structures without seeming to realise that they will be ignored. The <code>breadcrumb</code> property is described as "A set of links that can help a user understand and navigate a website hierarchy." The sole example of it is:

 <nowiki><div itemprop="breadcrumb">
  <a href="category/books.html">Books</a> >
  <a href="category/books-literature.html">Literature & Fiction</a> >
  <a href="category/books-classics">Classics</a>
</div></nowiki>

Microdata processing dictates that the value of the <code>breadcrumb</code> property in this case is <code>"Books Literature & Fiction Classics"</code>. The HTML content of this property isn't preserved by microdata processing, so it isn't actually a set of links but rather a textual description of the context of the page.

Other examples of microdata publishers assuming that the markup within content will be carried through into the data gleaned from the page [http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/0185.html have been identified]:

From http://www.goodreads.com/book/show/14770.Neuromancer

 <nowiki><div class="infoBoxRowItem" itemprop='awards'>
  <a href="/award/show/9-hugo-award" class="award">Hugo Award for Best Novel (1985)</a>, 
  <a href="/award/show/23-nebula-award" class="award">Nebula Award for Best Novel (1984)</a>, 
  <a href="/award/show/326-philip-k-dick-award" class="award">Philip K. Dick Award (1984)</a>, 
  <a href="/award/show/1403-john-w-campbell-memorial-award" class="award">John W. Campbell Memorial Award Nominee for Best Science Fiction Novel (1985)</a>                      
</div></nowiki>

From http://www.telegraph.co.uk/foodanddrink/restaurants/8824409/The-Butchers-Arms-Woolhope-Herefordshire-restaurant-review.html

 <nowiki><div id="mainBodyArea" itemprop="reviewBody">
  <div class="firstPar">
    <p>
      <strong>The Butchers Arms</strong>, Woolhope, Herefordshire HR1 4RF <br>
      <strong>Contact </strong>01432 860281; food@butchersarmswoolhope.co.uk).<br>
      <strong>Price </strong>Three courses with a couple of pints, or half a bottle of 
      wine and coffee: &pound;35-40 per head
    </p>
  </div>
  <div class="secondPar">
    <p>
      For a man whose first career was in advertising, Stephen Bull is no huge fan 
      of the hard sell. &ldquo;It&rsquo;s all much of a muchness, really,&rdquo; 
      replied the owner of The Butchers Arms near Hereford when asked to recommend a
      couple of his dishes. &ldquo;All pretty mediocre.&rdquo;
    </p>
    ...
  </div>
</div></nowiki>

=== URLs, URIs and IRIs ===

These HTML5 rules on URL resolution are [http://www.w3.org/Bugs/Public/show_bug.cgi?id=14693#c1 known to be broken] and will hopefully be fixed by reference to a revised IRI spec. This section documents the particular issues that arise from the current algorithm as it applies to RDFa processing.

HTML5 uses the term URL throughout. The [http://dev.w3.org/html5/spec/urls.html#valid-url definition that it uses for a valid URL] is:

:A URL is a valid URL if at least one of the following conditions holds:
:
:* The URL is a valid URI reference [RFC3986].
:* The URL is a valid IRI reference and it has no query component. [RFC3987]
:* The URL is a valid IRI reference and its query component contains no unescaped non-ASCII characters. [RFC3987]
:* The URL is a valid IRI reference and the character encoding of the URL's Document is UTF-8 or a UTF-16 encoding. [RFC3987]

This allows IRIs to appear within documents so long as the character encoding of the document in which the URL is found is UTF-8 or UTF-16.

DOM attributes whose values reflect HTML attributes whose values are URLs (such as <code>@href</code>, <code>@src</code>, <code>@itemid</code> and so on) are then resolved through the [http://dev.w3.org/html5/spec/urls.html#resolving-urls HTML5 resolution algorithm]. This turns all IRIs into URIs by percent-encoding characters that aren't allowed in URIs and performs resolution based on URI rules from [http://tools.ietf.org/html/rfc3986 RFC3986]. The results at the moment are always valid URIs.

In [http://www.w3.org/2010/02/rdfa/drafts/2011/ED-rdfa-core-20111020/#s_curieprocessing RDFa-Core], resolution of IRIs in all cases is done through the standard '''IRI''' resolution algorithm from [http://www.ietf.org/rfc/rfc3987.txt RFC3987]. The RDF restrictions on URIs used to identify resources is documented in its [http://www.w3.org/TR/rdf-concepts/#section-Graph-URIref abstract semantics]. This currently normalises IRIs to URIs by percent-encoding non-ASCII characters, so currently the effective RDF generated from RDFa will contain URIs.

The new draft of the [http://www.w3.org/TR/rdf11-concepts/#section-IRI-Vocabulary RDF 1.1 abstract semantics] allows IRIs to be used as identifiers for resources. For future RDF 1.1 implementations, the effective RDF generated from RDFa will contain IRIs. Importantly, since these IRIs are being used as identifiers, their equivalence will be assessed through [http://tools.ietf.org/html/rfc3987#section-5 string-equivalence] rather than by first normalising to URIs and then comparing.

This mismatch between HTML5 and RDF is a problem for people using RDFa 1.0 and 1.1 because the resolution of those URL attributes defined in HTML5 (<code>@href</code>, <code>@src</code> etc) differs from the resolution of URL attributes defined by RDFa (<code>@resource</code>, <code>@typeof</code> etc). Specifically, normalising IRIs to URIs and then resolving according to RFC3986 (URI resolution), which is what HTML5 does, might not (?) produce the same results as resolving IRIs according to RFC3987 (IRI resolution) and then normalising to a URI, which is what RDFa does.

It is also a problem when people are using RDFa and microdata side-by-side (or switching between them) because the URIs they use within <code>@itemid</code>, <code>@itemtype</code> and <code>@itemprop</code> will not be handled in the same way as those within <code>@about</code>, <code>@typeof</code> and <code>@property</code>, resulting in slightly different data in the two cases.

These discrepancies will be worse when RDF 1.1 is standardised and used with HTML+RDFa, as at that point some of the identifiers generated from HTML+RDFa processing will be normalised to URIs (those in <code>@href</code>, <code>@src</code> etc attributes) while others will be IRIs (those in <code>@resource</code>, <code>@typeof</code>, <code>@property</code> etc attributes).



[[Category:HTML Data TF]]