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 22:00:36 +0000
Cc: HTML Data Task Force WG <public-html-data-tf@w3.org>
Message-Id: <58DF8DF8-E8CE-485B-A474-6FF78CA75CFF@jenitennison.com>
To: Dan Brickley <danbri@danbri.org>
Dan,

On 30 Oct 2011, at 19:51, Dan Brickley wrote:
> On 30 October 2011 18:13, Jeni Tennison <jeni@jenitennison.com> wrote:
>> On 30 Oct 2011, at 10:55, Dan Brickley wrote:
>>> IMHO it's fine to say "If you want to mention another type, we expect
>>> the property <http://schema.org/type> to be available long term, and
>>> always to be defined as meaning the same thing as RDF's rdf:type
>>> property". What concerned me was the hint/suggestion that a mapping
>>> might reference that property more deeply, as an integral part of
>>> Microdata-as-RDF syntax.
>> 
>> We (as in this Task Force) need to create a microdata-to-RDF mapping and guidelines for publishers and consumers of microdata that will help it to fit into the wider ecosystem. If special-casing http://schema.org/type is out of the question, I see three possibilities around these rdf:type equivalent properties.
> 
> Can you give an example draft paragraph for how that special-casing
> would look? I don't want to mistakenly close the door on something
> useful. Meanwhile…

Well, you've pretty much persuaded me that we shouldn't do it :) But it would be something like:

In recommendations for publishers:

  If you need to publish microdata aimed at several different consumers
  that use different vocabularies, it may be that you can select a single
  main type (usually the one that has the most relevant properties) and
  provide any additional types with the property http://schema.org/type.
  You should check to make sure the consumers of these secondary types
  treat items the same way if their type is indicated through this
  property rather than through the @itemtype attribute.

In recommendations for vocabulary authors:

  Within your vocabulary definition, you should indicate whether, when
  a type in your vocabulary is indicated through a http://schema.org/type
  property, consumers should recognise the item as if that type had been
  indicated through the @itemtype property.

In recommendations for consumers:

  The http://schema.org/type property is a general-purpose mechanism for
  indicating secondary types for an item. When a vocabulary allows its
  use, an item that indicates a type in that vocabulary through the
  http://schema.org/type property should be treated as of that type for
  the purpose of categorising it (but not for the interpretation of
  non-URI properties on that item, which are always interpreted based on
  the type provided by the @itemtype attribute).

In the microdata to RDF conversion (with apologies to Gregg):

  If the URI of the property after expansion is http://schema.org/type
  then create the triple:

    <subject> rdf:type _value_ .

>> 2. We can say in the generic microdata->RDF conversion that individual vocabularies may define their own equivalents to rdf:type, and that these can be provided in the (growing) registry entry for the particular vocabulary, with schema.org's being http://schema.org/type. This will mean processors (or at least those that pick up the vocabulary information from the registry) will behave more regularly for those using them, and we can recommend both that vocabulary authors define an equivalent to rdf:type and that consumers that understand those vocabularies pick up on those properties when working out the type of an item. But it makes it a bit less regular for publishers, because instead of the advice "use the property http://schema.org/type" we will have to say, "use whatever type property has been specified for the vocabulary you're using, or rdf:type if there isn't one".
> 
> (...or schema.org if you want one with a short URL ?)

It depends on how it was defined. One way of doing vocabulary-specific type-defining properties is to use literals eg:

  <div itemscope itemtype="http://schema.org/Product">
    <meta itemprop="http://www.productontology.org/id/type" content="Hammer" />
    <meta itemprop="http://example.org/my_ontology.owl#type" content="Tool" />
    <!-- other schema.org properties go in here -->
  </div>	

Another would be to use URLs eg:

  <div itemscope itemtype="http://schema.org/Product">
    <link itemprop="http://www.productontology.org/id/type" 
          href="http://www.productontology.org/id/Hammer" />
    <link itemprop="http://example.org/my_ontology.owl#type" 
          href="http://example.org/my_ontology.owl#Tool" />
    <!-- other schema.org properties go in here -->
  </div>	

(Or you could have something that works with both kinds of values, interpreting as a URI if it's an absolute URI or constructing a URI from the vocabulary base of the property otherwise.)

If http://schema.org/type were defined to take URIs then it would also be possible to do:

  <div itemscope itemtype="http://schema.org/Product">
    <link itemprop="type" href="http://www.productontology.org/id/Hammer" />
    <link itemprop="type" href="http://example.org/my_ontology.owl#Tool" />
    <!-- other schema.org properties go in here -->
  </div>	

The flip side for all this is to have schema.org consumption defined such that the above were equivalent to:

  <div itemscope itemtype="http://www.productontology.org/id/Hammer">
    <link itemprop="http://schema.org/type" href="http://schema.org/Product" />
    <link itemprop="http://schema.org/type" 
          href="http://example.org/my_ontology.owl#Tool" />
    <!-- other schema.org properties go in here -->
  </div>	

> Ok, would it be useful then if FOAF also had 'type'? I can easily add
> that. Should we declare domains and ranges? It would help to have a
> standard package of triples to add to a schema.

If we went down this route, in the recommendations for vocabulary authors we would say something like:

  Microdata does not provide an easy way of defining an item as having
  multiple types from different vocabularies. If you want to make it
  possible for your vocabulary to be used with microdata and mixed with 
  others, you should define a type-equivalent property URI that can be 
  used on items whose primary type is not in your vocabulary to indicate 
  that the item is also of a type in your vocabulary.

  You should also state that consumers of your vocabulary should treat 
  items whose type is indicated in this way as being of that type for 
  processing purposes. For example, if consumers recognise comics through
  the type http://example.org/Comic and the example.org vocabulary
  defined the property http://example.org/type as being a type-equivalent
  property, then the following would be equivalent for consumers of 
  information about comics:

    <section itemscope itemtype="http://example.org/Comic">
      <link itemprop="http://schema.org/type" 
            href="http://schema.org/Product">
      <h1 itemprop="title http://schema.org/name">Batman</h1>
      ...
    </section>

    <section itemscope itemtype="http://schema.org/Product">
      <meta itemprop="http://example.org/type" content="Comic">
      <h1 itemprop="name http://example.org/title">Batman</h1>
      ...
    </section>

  It's recommended to use the generic http://schema.org/type property, 
  whose value can be a URI, or you may wish to define a property within 
  your own vocabulary, in which case for simplicity it's recommended
  that the required value is the name of a type in your vocabulary.

> Dublin Core btw already seems to have it: the dcterms:type property is
> close enough? Maybe more a subproperty... ie. every ?X dcterm:type ?Y
> implies the same with rdf:type, but perhaps not vice-versa.

Interesting.

> See http://dublincore.org/documents/dcmi-terms/#terms-type ... it even
> has range rdfs:Class (maybe that also is bad for OWL DL? :)

Dunno.

>> 3. We can define http://www.w3.org/ns/type as having special handling in the microdata to RDF conversion and recommend its use for publishers. This has clarity and eases the burden on vocabulary authors and consumers as they only have to recognise a single type. But if there is also a http://schema.org/type, publishers who are using schema.org (the vast majority) will probably use it (or the short-form "type") instead of http://www.w3.org/ns/type or will have to use itemprop="type http://www.w3.org/ns/type" all the time.
>> 
>> I think 2 or 3 are preferable, and which route we go really depends on whether schema.org defines a http://schema.org/type property or not. If you/they do, we will need to do 2. It would be helpful to know which is going to happen sooner rather than later so that we can create appropriate advice.
> 
> I don't see any opposition to adding http://schema.org/type ... could
> you write up a Wiki page entry somewhere that encapsulates in a single
> read the entire proposal so we can get it reviewed and OK'd by these
> two TFs and by the Schema.org partners? Or maybe I should try that, as
> an exercise to make sure I've gotten the point this time :)

I'm not sure that there is support for this Task Force to encourage or discourage http://schema.org/type. When we discussed this a couple of weeks ago, preferences seemed to be towards a single generic type-equivalent property (that wasn't rdf:type because of its spelling) rather than vocabulary-specific properties as described in #2 above. I was keen on http://schema.org/type for simplicity, but as I say, you've persuaded me that it's not appropriate to use as a generic type-equivalent property because of the status of schema.org as a vocabulary. If W3C defined http://www.w3.org/ns/type instead, we would not want schema.org to define http://schema.org/type as it would divert people away from using http://www.w3.org/ns/type (which would be recognised by the microdata to RDF conversion when http://schema.org/type would not).

Can we let people get back from the weekend and see whether there are any more opinions about this topic?

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com
Received on Sunday, 30 October 2011 22:01:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 30 October 2011 22:01:07 GMT