Category: html5

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 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:

schema.org

<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>
  </div>
  <span itemprop="genre">Science fiction</span>
  <a href="../movies/avatar-theatrical-trailer.html" itemprop="trailer">Trailer</a>
</div>

RDFa

<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>
 </div>
 <span property="genre">Science fiction</span>
 <a rel="trailer" href="../movies/avatar-theatrical-trailer.html">Trailer</a>
</div>

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>
</div>

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!
</div

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!

Update:

By specific request, RDFa for geo tagging:

schema.org

<div itemscope itemtype="http://schema.org/Place"
 <h1>What is the latitude and longitude of the <span itemprop="name">Empire State Building</span>?<h1>
 Answer:
 <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" />
 </div>
</div>

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>
 Answer:
 <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" />
 </span>
 </div>
</div>

RDFish RDFa

 <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>
 Answer:
 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" />
 </div>
</div>

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.