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

Re: Multiple types from different vocabularies (ACTION-7)

From: Jeni Tennison <jeni@jenitennison.com>
Date: Sun, 30 Oct 2011 06:38:27 +0000
Cc: Ivan Herman <ivan@w3.org>
Message-Id: <06047A7C-715B-499D-B6CB-FB7D90717F32@jenitennison.com>
To: HTML Data Task Force WG <public-html-data-tf@w3.org>
Picking up on this from a while ago…

Given that a common 'other types' property is a reasonable workaround in some circumstances for the fact that microdata won't support multiple types from different vocabularies itself, we do need to sort out whether we recommend / support in a microdata-to-RDF mapping any other property.

On 16 Oct 2011, at 10:25, Ivan Herman wrote:
> However, *if* we consider microdata as a simple syntax to add structured data to HTML which happens to be used by schema.org as well (even if we say that for which schema.org is the biggest 'customer'), but can also be used, eg, to encode microformat vocabularies, then using a schema.org/type is not really the good solution. Indeed, I do not see any major difference between using schema.org/type or www.w3.org/ns/type or, for that matter, the current rdf:type: indeed, in my view usage of *all* these options are equally bad insofar as it binds microdata to a particular vocabulary which, as far as I can understand it, is not the design of microdata. (Let us forget about the microdata->RDF mapping which is a different matter.)


None of these properties bind microdata to using any particular vocabulary, as it is always possible to use the URI version of the property with any type. It comes down to two factors: what property URIs we might reasonably use (eg Ivan indicated that http://www.org/type would be hard to support) and what will be easy for people to use.

Given the three options:

 1. http://www.w3.org/1999/02/22-rdf-syntax-ns#type
 2. http://www.w3.org/ns/type
 3. http://schema.org/type

#2 and #3 have the clear advantages over #1 of brevity, readability and rememberability.

#3 has the clear advantage over #2 that in the very common case where someone is using a schema.org type they do not have to write out the full URI. Here are a couple of examples:

A. w3.org/ns/type with schema.org item type

  <div itemscope itemtype="http://schema.org/Place" itemid="#store">
    <link itemprop="http://w3.org/ns/type" 
          href="http://purl.org/goodrelations/v1#Location" />
    ...
  </div>
  
B. schema.org/type with schema.org item type

  <div itemscope itemtype="http://schema.org/Place" itemid="#store">
    <link itemprop="type" href="http://purl.org/goodrelations/v1#Location" />
    ...
  </div>

C. w3.org/ns/type with non-schema.org item type

  <div itemscope itemtype="http://purl.org/goodrelations/v1#Location" itemid="#wc">
     <link itemprop="http://w3.org/ns/type" 
           href="http://www.productontology.org/id/Public_toilet" />
     ...
  </div>

D. schema.org/type with non-schema.org item type

  <div itemscope itemtype="http://purl.org/goodrelations/v1#Location" itemid="#wc">
     <link itemprop="http://schema.org/type" 
           href="http://www.productontology.org/id/Public_toilet" />
     ...
  </div>

In these examples, there's really nothing in it between C and D, but there's a clear win of B (schema.org/type) over A (w3.org/ns/type) in the most common case of a schema.org item type.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com
Received on Sunday, 30 October 2011 06:38:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 30 October 2011 06:39:00 GMT