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

Martin,

On 14 Oct 2011, at 09:32, Martin Hepp wrote:
> My simple take is to define a reserved keyword "secondaryType" for itemprop that is used for attaching additional types without creating ambiguity about the scope of the properties. Semantically, this would be equivalent to rdf:type, and you will want to allow multiple of those.
> 
> The nice thing of this approach is:
> 
> 1. You could start by simply adding this to http://schema.org/Thing without a need to update the Microdata spec first. So you could get this done within a day. 
> 2. You could later add this to the spec.
> 3. There is no confusion about the scope of local properties.
> 4. The mapping to RDF is trivial (simply use the full URI of rdf:type).
> 5. You do not introduce a new Microdata core keyword, just a predefined property.
> 
> Example
> 
> <div itemscope itemtype="http://schema.org/Product">
>  <link itemprop="secondaryType" href="http://www.productontology.org/id/Hammer" />
>  <link itemprop="secondaryType" href="http://example.org/my_ontology.owl#Tool" />
> <!-- other schema.org properties go in here -->
> </div>	
> 
> One prop, and you will be all set, and the SW community and the search engines can live and prosper in love, peace and harmony ;-)


You have a dream, huh? ;)

I think this is a promising direction, but there are several variants to consider.

1. A reserved short property name. I don't think this is effective unless it's in the microdata spec and I think that the only chance of that is if Hixie were convinced of the requirement to support multiple types from different vocabularies, in which case he could well decide to support that requirement in some other way.

2. A recommended short property name. We could have a guideline for vocabulary authors that said "always define a property 'type' (or 'secondaryType' or whatever) so publishers can associate types from other vocabularies to items when they use your vocabulary". The problem with that is that not everyone will do it (eg you're not going to find Hixie adding a 'type' property to the vCard or iCalendar vocabularies unless you convince him of the requirement etc etc) and that you couldn't be certain that every vocabulary was using 'type' with those semantics (this becomes less of an issue the more obscure you make the name).

3. Vocabulary-specific properties. We could have a guideline for vocabulary authors that said "to enable your types to be used where publishers are using a different primary type, define a property that can be used for attaching your types to items; for consistency across vocabularies, we recommend this having a local name of 'type' and taking values that are the local names of types in your vocabulary". In your example above this would mean:

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

which isn't bad.

This puts the onus on vocabulary authors to decide whether they want their vocabulary to be usable when a publisher is primarily using a different type. Vocabulary authors already have to make that decision: if they don't specify URI equivalents for their properties then publishers can't use those properties on items which have types outside their vocabulary. So while this can mean an inconsistent picture for publishers, it's no more inconsistent than it currently is.

There are two disadvantages from an RDF perspective.

The first is that it would mean adding this property to existing vocabularies to make them microdata ready. You could argue that to use existing RDF vocabularies in microdata you have to do some extra work anyway (as Hixie has pointed out, you can't just port them because there are extra semantics you have to define for microdata use), so adding another property isn't a big deal, but some vocabularies may be very hard to change.

The second is that it wouldn't be possible for a generic microdata-to-RDF mapping to map these properties into an rdf:type relationship, so data that used this pattern would always have to go through a vocabulary-specific conversion to become usable RDF.

4. A global property. This could be rdf:type or we could recommend that the W3C define an equivalent property but with a more approachable URI, such as 'http://w3.org/ns/global/type'. In your example, that would mean:

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

This has the advantage of having a consistent way of adding types, but makes the markup more cluttered than the previous solutions. However easy you make the URL for the type, it's always going to be something that people have to work to remember; given it'll be cut-and-pasted anyway, you might as well use the existing rdf:type rather than inventing something with an equivalent semantics.

My summary is that I don't think that a reserved or recommended short property name will work, but either vocabulary-specific properties or a global property (or a combination of both) might.

Thoughts?

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

Received on Saturday, 15 October 2011 04:40:25 UTC