W3C home > Mailing lists > Public > public-html-data-tf@w3.org > October 2011

Re: Microdata to RDF: First Editor's Draft (ACTION-6)

From: Lin Clark <lin.w.clark@gmail.com>
Date: Fri, 14 Oct 2011 11:28:24 +0100
Message-ID: <CACho_As+StdFR=aVLxwxioEw7rsQt1HjrK_Bt5sbEoe2Nou-fg@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: public-html-data-tf@w3.org, Richard Cyganiak <richard.cyganiak@deri.org>
On Fri, Oct 14, 2011 at 9:52 AM, Philip Jägenstedt <philipj@opera.com>wrote:
> This kind of mapping can only really be done on a vocabulary-specific
> basis, for vocabularies that define both forms to be equivalent.

There's an idea for how to deal with the vocabulary-specific nature of
microdata's itemprops which came out of discussions Richard Cyganiak and I
had a few months ago. Richard has given it more thought than I have, so I'm
CCing him here. Hopefully he has a chance to give his input.

There could be a registry that indicates whether or not the itemtype defines
both the token and the URI form to be equivalent.

This registry could also define a small number of patterns for forming the
URI from the combination of the itemtype and the token. For example, one
pattern would be to take the domain, without the path to the itemtype, and
append the itemprop token as schema.org does. There would probably be around
3 patterns. Then, a vocabulary could be registered as following one of those

By defining these patterns, it would give clear indication to vocabulary
publishers how they can create a vocabulary that works for both microdata
and RDF. Also, since the number of patterns would be limited to a small set
with clear rules, it wouldn't put too much burden on consumers that want to
translate microdata into RDF.

Anyone would be able to identify in the registry which pattern a vocabulary
uses (or if it does not follow a pattern because it does not allow URIs), so
this information could be crowdsourced and wouldn't depend on the vocabulary
producer registering it. I imagine it could be much like prefix.cc in its

Received on Friday, 14 October 2011 10:28:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:08:24 UTC