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

Dan,

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.

1. We can treat http://schema.org/type and other type-equivalent properties like any other property, not say anything special about it or recommend its use, and leave it to consumers to do any post-processing on the results of the generic microdata->RDF conversion. I have a feeling that (as Ivan says) some processors will try to be helpful and automatically do some post-processing, while others will stick with the letter of the conversion algorithm and not do so. That leads to a confusing situation for people using those processors, who will only see the variant behaviour and probably won't understand its cause. It also means we can't give any guidelines to consumers about understanding microdata additional types are provided through a separate property.

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".

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.

>> This is really down to how schema.org is pitched and the role it wants to play. If it's an external project that might at any moment disappear or be led off in a different direction by a collection of self-interested vendors, then I agree with you. If it's a web-community-based project that is being developed through a light-weight but defined and open process with W3C support and backing then it's much less clear cut; my inclination is to encourage it in that direction.
> 
> It has elements of the former, but leans towards the latter. However,
> it isn't a democracy, so a lot depends on what people mean by 'open
> process' here. I've tried to outline a process for how the Schema.org
> project and the Web Schemas TF are related here:
> http://www.w3.org/wiki/SchemaDotOrgProcess ... maybe you could have  a
> glance and see how that style fits with the needs here.

OK, I don't think so based on that.

>>> Yup. Has anyone talked to Hixie about this lately?
>> 
>> Yes we did, here. [1] He's not going to add support for multiple types from different vocabularies to microdata syntax unless and until they have common use (both being published and consumed). None of the evidence that we are able to provide of that happening at the moment is widespread enough to be persuasive to him.
> 
> Thanks. Does that conversation have an URL?

The thread started at the reference I gave:

  http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/0064.html

and can be followed through the 'Next message in thread' links. Or you can see the thread on the thread-centric page at:

  http://lists.w3.org/Archives/Public/public-html-data-tf/2011Oct/thread.html

But you know how W3C mailing lists work so I guess that's not what you're asking for?

>> There are other workarounds to support multiple types, such as just using RDFa, mixing microdata with other syntaxes to supply the extra information, or using hidden sections of the document. We're going to have to present the full range of options, but the extra type property is the easiest to use in simple circumstances.
> 
> Great. I'll investigate whether I can find some use cases for
> producing/consuming...


That would be great. I've been using some of the recent blekko.com searches to identify pages that contain microdata and microformats that we might use as a starting point to explore these issues. Martin Hepp also has a bunch of examples around GoodRelations use.

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com

Received on Sunday, 30 October 2011 17:14:13 UTC