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

*Formally* one can of course put an 

<http://schema.org/type> owl:equivalentProperty <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> .

into the schema.owl file. But if we do that, strictly from the Semantic Web/OWL world (I know, this may be of no interest for many, but I still have to consider that) what this would mean is that schema.owl would push everything into OWL Full (it is not allowed in OWL DL to make statements on the core vocabulary). If anybody ever would like to use the schema.org vocabulary within the framework of a more complex reasoning but staying within OWL DL, then that person would be doomed. Strictly speaking, even OWL 2 RL would break, though that is the closest to any ground RDF reasoning around. The same holds, of course, if we used www.w3.org/ns/type. That is _one_ of the reasons I was saying that this is equally bad. (I do not think this is a far fetched possibility. Elsewhere in one of the threads the issue of mixing schema.org terms with, say, medical ontology terms came up, and that would be a very reasonable thing to do. The medical informatics world makes a significant use of OWL reasoning with their particular ontologies. Ie, we are not talking about exclusively research topics here.)

The alternative is that microdata->RDF mapping would have an extra rule that makes a mapping of schema.org/type to rdf:type, essentially breaking the uniformity of the mapping. The same for an RDFa mapping for the schema.org vocab. A hack, that is.

There is no doubt in my mind that the clean solution would be to allow for a multiple type on the microdata syntax level, just as RDFa does. Anything else is a hack, and an ugly one at that. We may have to go there, but we should be aware of what we are doing...

Ivan


On Oct 30, 2011, at 07:38 , Jeni Tennison wrote:

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


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf