time vs data

There is a bug in HTML5 to remove time and replace it with data.

I think in general that <data> isn’t a bad idea. I agree that only being able to talk about <time> was a bit odd, and that many other values have the same effective use case. As mentioned by Ian Hixen:

  • dimensionless numbers (2.3)
  • numbers with units (5kg)
  • enumerated values, like months (February) or days of the week (Monday)
  • durations

However, I don’t think that data as it stands right now is done. As this example of the old <time> and new <data> shows there is a fairly heavy semantics loss from the change.

Published <time pubdate datetime="2009-09-15T14:54-07:00">on 2009/09/15 at 2:54pm</time> 

Assigned data to RDF via magic human transformation step simply to talk about what data is there. Displayed in Turtle.

 @prefix magic: <https://gavin.carothers.name/vocabs/magic#> . 
<> magic:pubdate "2009-09-15T14:54-07:00"^^xsd:dateTime . 

The HTML contains a reasonable amount of data. We know that the contents of datatime is an ISO datatime, we know that the relationship between that date time and the page is it’s publication date.

Published <data value="2009-09-15T14:54-07:00">on 2009/09/15 at 2:54pm</data> 

Again magic human transformation to Turtle.

@prefix magic: <https://gavin.carothers.name/vocabs/magic#> . 
[] magic:unknown "2009-09-15T14:54-07:00" . 

This time around don’t know much at all. We know that “2009-09-15T14:54-07:00” may some how be related to the current page. We don’t know how the string is formated, nor how the string is related to the page if it is at all.

As currently proposed <data> sure looks like a step backwards, but maybe it can be a step forward.

Just some invalid markup:

<data type="dateTime" value="2009-09-15T14:54-07:00" property="pubdate"> 

Just some RDFa:

<data datatype="xsd:dateTime" content="2009-09-15T14:54-07:00" property="magic:pubdate"> 

Just some microdata plus some datatype:

<data type="dateTime" value="2009-09-15T14:54-07:00" itemprop="pubdate"> 

Adding a generic data element without data typing doesn’t seem like a good idea. With datatyping I can see it working better then creating an element for every kind of data.


schema.org as RDFa (Part I)

schema.org an initiative by Google claims once again that RDFa is too complicated. That’s not really true. Here in fact are the first examples from schema.org in RDFa. There is a bonus as well for using RDFa rather then Microdata… you can test that RDFa is valid and gives you what you expect TODAY. Microdata and schema.org? No validation (STILL!), and no public parsers.

A movie

The first example from Schema.org is about marking up a movie:

<div itemscope itemtype ="http://schema.org/Movie">
  <h1 itemprop="name"&g;Avatar</h1>
  <div itemprop="director" itemscope itemtype="http://schema.org/Person">
  Director: <span itemprop="name">James Cameron</span> (born <span itemprop="birthDate">August 16, 1954)</span>
  <span itemprop="genre">Science fiction</span>
  <a href="../movies/avatar-theatrical-trailer.html" itemprop="trailer">Trailer</a>
<div vocab="http://schema.org/" typeof="Movie">
 <h1 property="name">Avatar</h1>
 <div rel="director">Director:
   <span typeof="Person"><span property="name">James Cameron</span>
   (born <time property="birthDate" datetime="1954-08-16">August 16, 1954</time>)
 <span property="genre">Science fiction</span>
 <a rel="trailer" href="../movies/avatar-theatrical-trailer.html">Trailer</a>

That wasn’t very complicated. In fact compared with the example on Schema.org, why do some attributes need fully qualified URIs/IRIs and some don’t? How does microdata know that director is refering to schema.org’s director and not some other one?

Next is Spinal Tap!

<div vocab="http://schema.org/" typeof="Event">
 <div property="name">Spinal Tap</div>
 <span property="description">One of the loudest bands ever
 reunites for an unforgettable two-day show.</span>
 Event date:
 <time property="startDate" datetime="2011-05-08T19:30">May 8, 7:30pm</time>

Okay not even bothering with the Microdata/schema.org version. There are a few differences but not much. Where is all this complexity that RDFa introduces?

An offer, for a blender

<div vocab="http://schema.org/" type="Offer">
 <span property="name">Blend-O-Matic</span>
 <span property="price">$19.95</span>
 <link rel="availability" href="http://schema.org/InStock"/>Available today!

Yeah, still not seeing why RDFa is more complicated.

Okay, that’s all I feel like dealing with before breakfast. Will look a few more later.

In the mean time, gratuitous baby pictures!


By specific request, RDFa for geo tagging:

<div itemscope itemtype="http://schema.org/Place"
 <h1>What is the latitude and longitude of the <span itemprop="name">Empire State Building</span>?<h1>
 <div itemprop="geo" itemscope itemtype="http://schema.org/GeoCoordinates">
 Latitude: 40 deg 44 min 54.36 sec N
 Longitude: 73 deg 59 min 8.5 dec W
 <meta itemprop="latitude" content="40.75" />
 <meta itemprop="latitude" content="73.98" />
schema.org as RDFa
<div vocab="http://schema.org/" typeof="Place"
 <h1>What is the latitude and longitude of the <span property="name">Empire State Building</span>?<h1>
 <div rel="geo">
 Latitude: 40 deg 44 min 54.36 sec N
 Longitude: 73 deg 59 min 8.5 dec W
 <span typeof="GeoCoordinates">
 <meta property="latitude" content="40.75" />
 <meta property="longitude" content="73.98" />
 <div prefix="schema: http://schema.org/ dc: http://purl.org/dc/terms/ pos: http://www.w3.org/2003/01/geo/wgs84_pos#" 
  typeof="schema:Place pos:SpatialThing"
 <h1>What is the latitude and longitude of the <span property="dc:title schema:name">Empire State Building</span>?<h1>
 Latitude: 40 deg 44 min 54.36 sec N
 Longitude: 73 deg 59 min 8.5 dec W
 <meta property="pos:latitude schema:latitude" content="40.75" />
 <meta property="pos:longitude schema:longitude" content="73.98" />

As with the earlier conversions, these are 5 minute jobs without really spending much time thinking about them. But these WORK, can be validated today and are still very simple. The RDFish version above does start to use some RDFa features that are considered confusing. It uses 3 vocabularies rather then just one. To do this it does use the much feared PREFIX. I’ve covered my opinion of prefixes before. I still stand by my statement that prefixes are simply not that complicated. Also, the RDFish version does drop the added GeoCoordinates instance, and intermediate schema:geo property, didn’t really see why they were there. Other possible improvements include adding datatypes to the properties in RDFa, but that’s not really necessary in this case.

Understanding Microdata, now with more understanding

Okay, I’m giving this whole HTML5 microdata a shot for real. 4475 HTML pages of it in fact.

After reading what Hixie wrote, tried creating a new sample. Didn’t feel any stranger then the markup for RDFa. From a typing perspective, it is annoying to have to type the whole URI, from a reading perspective it’s much clearer what’s going on, at least to me. I also won’t be typing these every time, template systems are neat like that. Now as far as I can tell the XHTMLy solution to this using XML entities is not supported in HTML5.

Should have known better then to jump right from the sample into doing template markup. Having spent the morning making sure that I was producing valid HTML5, the addition of microdata caused errors at Validator.nu. It seems the method of using <link> elements is not currently supported by the validator. In fact even our sample fails to validate. Ugh.

Philip’s parser works nicely for testing to see if what I have is working, given that I can’t use the validator.

At this point I have markup for the relationships of Manifestations of an edition (Expression). Adding the markup for the publication dates was much more unpleasant. It seems that I have to repeat the whole:

     <link itemprop="about" href="${product.subject}">

every time I need to talk about ${product.subject}. And the microdata parser happily adds the relationship all over again.

  <http://vocab.org/frbr/core#embodiment> <urn:x-domain:oreilly.com:product:9780596007683.BOOK> ;
  <http://vocab.org/frbr/core#embodiment> <urn:x-domain:oreilly.com:product:9780596806316.BOOK> ;
  <http://vocab.org/frbr/core#embodiment> <urn:x-domain:oreilly.com:product:9780596802189.EBOOK> ;
  <http://vocab.org/frbr/core#embodiment> <urn:x-domain:oreilly.com:product:9780596802028.SAF> ;
  <http://vocab.org/frbr/core#embodiment> <urn:x-domain:oreilly.com:product:9780596007683.BOOK> ;
  <http://vocab.org/frbr/core#embodiment> <urn:x-domain:oreilly.com:product:9780596806316.BOOK> ;
  <http://vocab.org/frbr/core#embodiment> <urn:x-domain:oreilly.com:product:9780596802189.EBOOK> .

There is a great deal of markup smell coming from this page now. I think from here I’m going to try this as XHTML (5?) and go back to RDFa and see how that goes.

Will send this and earlier post to WhatWG mailing list as soon as my subscription to the WhatWG mailing list is approved.

Trying to understand Microdata? RDFa?

Been trying to follow the RDFa, microdata messwork. This isn’t academic. I have a nice open ticket that says “Insert inline metadata into O’Reilly Catalog pages” which is due in a large release at the end of September.

Do I expect Google to index my page a whole lot better? Nah. (That’s why we’re doing complete HTML chapters of our books, and full HTML Table of Contents). Do I expect our internal tools to index it better? Maybe, if I pray to the right search gods. Can I think of some some crazy shit to do in jQuery with the few attributes I have in there? Oh yes. What exactly is going to come of us putting micodata in our pages? No clue, but then we didn’t really know what Web 2.0 was in 2004, or this strangeWorld Wide Web ( Online Whole Internet Catalog, in which we uh, printed the internet) thing was in 1992.

Lets get started. I know what metadata I need to express. Here is a short version of it expressed in Turtle. There are a number of other fields, but this will give you the gist.

@prefix dc: <http://purl.org/dc/terms/> .
@prefix frbr: <http://purl.org/vocab/frbr/core#> .

<http://purl.oreilly.com/works/45U8QJGZSQKDH8N> a frbr:Work ;
     dc:creator "Wil Wheaton"@en ;
     dc:title "Just a Geek"@en ;
     frbr:realization <http://purl.oreilly.com/products/9780596007683.BOOK>,
         <http://purl.oreilly.com/products/9780596802189.EBOOK> . 

<http://purl.oreilly.com/products/9780596007683.BOOK> a frbr:Expression ;
     dc:type <http://purl.oreilly.com/product-types/BOOK> . 

<http://purl.oreilly.com/products/9780596802189.EBOOK> a frbr:Expression ;
     dc:type <http://purl.oreilly.com/product-types/EBOOK> .

This sample uses two vocabularies that exist in the wild. Dublin Core, which is a very mature standard developed by a reasonably heavy weight process with many serializations, and uses. FRBR too is a standard developed by a rather austere body the International Federation of Library Associations and Institutions the RDF realization of it however isn’t from them but rather a few guys who needed to represent it. Reasonably smart few guys, but no giant standards body here.

Took about 15 minutes to whip up a simple RDFa based representation. Now, I know RDF reasonably well, XML very well, and have decent HTML skills. So I admit my experience is not going to be the norm, but it didn’t feel a whole lot harder then the first time I was trying to use hCard. I screwed up a few times, mixing up where to use rel= vs. property=. I also forgot that I can’t just stick a <UL> in another <UL>, need the picky <LI>, also left off at least one close tag. Made all those mistakes in just 32 lines of HTML. But a few quick iterations with validation and it was all green check boxes. I screwed up my late night hand written HTML at about the same rate I screwed up RDFa attributes. I had read the RDFa primer two months ago, but didn’t remember much other then there were some attributes and they went on some tags. Didn’t use the primer, just looked at the example content from RDFa4Google. Used Elias Torres RDFa parser to test my results and validator.w3.org for my HTML.

Felt reasonably happy with my RDFa result. Worked as expected. Microdata time!

Okay, got my Microdata spec. Finding a validator or parser however did not go well. 5 minutes in Google and Bing, turned up the expected HTML5 validator.nu but nothing in the way of a microdata validator or parser. I’ll be honest I was very tempted to stop here. Given the mistakes I made with RDFa, I’m very skeptical of my ability to write Microdata without the help of a parser. But I imagine there is one, and once I post this someone will tweet about it 5 minutes later.

Huh, okay, I have my outer item for the Work:

<div id="http://purl.oreilly.com/works/45U8QJGZSQKDH8N" 
          <span itemprop="http://purl.org/dc/terms/title">
            Just a Geek</span></li>
          <span itemprop="http://purl.org/dc/terms/creator">
            Wil Wheaton</span></li>

That wasn’t very hard at all. I’m completely lost at how to relate that work to the two expressions however. It looks like I’m limited to my microdata being in an <a> tag link to the expressions. And I really don’t understand the idea behind:

The value is the element’s textContent.

Does this mean I can’t use any data that isn’t displayed directly on the page? If the data would be better expressed in a machine readable form? In my case product type http://purl.oreilly.com/product-types/EBOOK really isn’t very human friendly. Ideas on how to express the same metadata or equivalent in microdata are very welcome. This is the best I could do.

I was expecting more tooling and examples from Microdata given it’s inclusion in HTML5. I was very surprised by the lack of tooling and almost complete lack real world examples.