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

On Oct 30, 2011, at 3:00 PM, Jeni Tennison wrote:

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

I think the way to do this is in a similar manner to how RDFa solved it (http://www.w3.org/2010/02/rdfa/drafts/2011/ED-rdfa-core-20111020/#s_vocab_expansion): basically, they should define properties which are a sub-type of rdf:type. The vocabulary-aware consumer can then perform limited RDFS entailment in order to have the rdf:type triple asserted. If we have a vocabulary registry, would could recommend that processors perform the same limited entailment that RDFa does. Without a registry, it could be done based on vocabulary discovery.

For example, at schema.org, assert the following:

schema:type a rdfs:Property; rdfs:subPropertyOf rdf:type .

A Microdata example could then be the following:

<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"/>
</div>

Assuming schema.org is a registered vocabulary in a registry, and that mutli-valued items do not create RDF Collections, this would generate the following in Turtle:

@prefix schema: <http://schema.org/> .
[ a schema:Product;
  schema:type <http://www.productontology.org/id/Hammer>,
                          <http://example.org/my_ontology.owl#Tool> ] .

After vocabulary expansion (limited RDFS entailment), it would generate the following:

@prefix schema: <http://schema.org/> .
[ a schema:Product,
     <http://www.productontology.org/id/Hammer>,
     <http://example.org/my_ontology.owl#Tool>;
  schema:type <http://www.productontology.org/id/Hammer>,
                          <http://example.org/my_ontology.owl#Tool> ] .

>> 

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

Literal types would be a problem.

> 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

Gregg

Received on Monday, 31 October 2011 18:53:19 UTC