W3C home > Mailing lists > Public > public-html@w3.org > October 2009

Re: Microdata vocabulary syntax

From: Tom Morris <tom@tommorris.org>
Date: Tue, 6 Oct 2009 10:03:16 +0100
Message-ID: <d375f00f0910060203ud53d8d0h95b6e334be55b330@mail.gmail.com>
To: John Giannandrea <jg@metaweb.com>
Cc: public-html@w3.org
On Mon, Oct 5, 2009 at 23:00, John Giannandrea <jg@metaweb.com> wrote:
> I would like to suggest that the spec can be simplified further by removing
> the reversed DNS labels.
>
> Microdata supports short unqualified names, as well as fully qualified URIs
> for itemprop, itemid and itemtype. As far as I can determine the reverse
> DNS labels do not provide any more functionality than URIs so the spec could
> be simplified by eliminating the duplication. The argument could be made
> that reverse DNS labels are nicer to look at, but if aesthetics are
> important then authors will presumably use itemtype and short property
> names.
>
> I also have a concern that the reverse DNS syntax introduces a new idiom
> (e.g. that http://example.com/foo == com.example.foo) which is new to the
> web. While URIs have their own issues, they are well known to the web
> community.
>

I concur. I do not know how the reverse DNS names are supposed to work
in practice.

com.example.foo - does that translate to http://example.com/foo - or
does it translate to http://foo.example.com/ ?

According to the specification, it refers to http://example.com/foo

But there is nothing in "com.example.foo" that automatically
distinguishes one from the other.

What if a company or organisation that is naming a microdata property
is not permitted to name that property in their organisation's 'root'
domain? Here is an example:

The Department of Computing at Imperial College decides to use
microdata on their website to describe computing resources. So they
decide that uk.ac.ic.doc.whatever is the property name. Under 2.4.9
of HTML5 specification, this ought to be understood as
http://ic.ac.uk/doc/whatever

But the Department of Computing hasn't been assigned internally the
right to use /doc/whatever - perhaps the /doc/ path of ic.ac.uk is
assigned to something else - the campus doctor maybe. How do they turn
http://doc.ic.ac.uk/whatever into a 2.4.9-compliant reversed DNS
string?

When microdata was initially mooted, a comparison was made to Java's
package naming system. Here is a perfect example. Jena, the RDF
library for Java, has the package name of com.hp.hpl.jena.* - the only
meaning that this is to convey is to help users identify the broad
source of Jena. But it is itself not produced by hp.com/hpl/jena -
it's produced by hpl.hp.com (Hewlett-Packard Labs).

The whole point of using URIs in a data format like RDF is to allow
lookup - it means that if you don't know what a property means, you
can go and look it up. If I'm a Chinese speaker and I get back the
word 'name', I have to go and learn English or ask someone who speaks
both Chinese and English what it means. If I get back
http://xmlns.com/foaf/0.1/name then I can - at least in theory - load
that URI and get more information about that property - maybe a label
and description of it's use in my native language. That could be in
something like RDF using OWL (or in OWL2's XML format), or it might
just be HTML or a few other formats. Does microdata support that kind
of architecture given that many property names are not directly
mappable to URIs?

The FOAF example is a good one. Given that someone might want to use
microdata reverse-domain syntax as per 2.4.9 to implement FOAF
properties in their document (I dunno, Google maybe? ;) ) - how does
one take http://xmlns.com/foaf/0.1/name and turn it into 2.4.9
reverse-domain syntax? Specifically, how does one escape the "." in
"0.1". Surely, com.xmlns.foaf.0.1.name translates to
http://xmlns.com/foaf/0/1/name under 2.4.9? Is this kind of thing
likely to cause some confusion for users of microdata syntax?

And yes, I'm an RDFa (and GRDDL) partisan. Molotov cocktails to the
usual address.

-- 
Tom Morris
<http://tommorris.org/>
Received on Tuesday, 6 October 2009 09:03:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:09 UTC