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

Hi Jeni, all:

My take is that if schema.org defines the property "secondaryType" for http://schema.org/Thing, this will be sufficient for 99 % of the cases. After all, schema.org is the only major Microdata vocabulary out there (IMHO).

It would also not depend on an immediate solution in the Microdata spec, so all the politics and delay in standardization are less of a problem.

Actually, I think it would have orders of magnitude more impact if we had this  ins schema.org than if we had it fixed in any W3C spec.

As for a global property defined e.g. in the W3C namespace, I think that is just a tiny bit less ugly than using the full URI for rdf:type.

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

I would be interested to learn what those are. IMO, the only really important thing you need is to define, in plain English, how URIs for properties should be formed 

a)base URI + local name or 
b) URI of the itemtype + local name of the property.

This is at least the approach we take with GoodRelations. Did I overlook anything?

Martin


On Oct 15, 2011, at 6:39 AM, Jeni Tennison wrote:

> 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 18:49:43 UTC