Re: Multiple itemtypes in microdata

On Thu, Oct 13, 2011 at 7:28 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 13 Oct 2011, Stéphane Corlosquet wrote:
> >
> > Here is a concrete example covering the case of multi-vocabulary use on
> > a property and on a type. At the schema.org workshop, I had a discussion
> > with Rachel Sanders who is working on improving the scholarly article
> > type for schema.org. She's sent several properties to be added to the
> > schema.org scholarly article type [1]. Many of them are very generic,
> > and she gave me the example of the PubMed ID property which would
> > probably not be accepted on schema.org because it is too specific to the
> > biomedical field.
>
> This is exactly the use case that URL properties are intended for. You
> don't need a new type here -- the type is still the schema.org scholarly
> article type, you just define a new property for the PubMed ID whose name
> is a URL and that is defined as being intended to be used with the
> schema.org scholarly article type with the semantic of "this gives the
> PubMed ID for article" (defining the syntax, error handling rules, etc).
>

We're in agreement here. I know that microdata offers this option via
absolute URIs in @itemprop. I was just replying to Henri's point about multi
vocabulary publishing and de facto vocabularies.



> > I also asked her about the various article types which the Drupal
> > Bibliography module supports (e.g. Conference proceedings, Book Chapter,
> > Thesis). Again, these seemed to be too specific for a generic vocabulary
> > like schema.org, and would need to be take from a domain specific
> > vocabulary.
>
> If you're extending an existing vocabulary, there's only one vocabulary,
> not two. You're not forced to use another type here.
>

In this case I would not extend the generic vocabulary (say schema.org), but
use an additional type from separate domain specific vocabulary (bibo, or
dbpedia) which includes the accurate type I want to use.


It's not clear, however, what the other consumer is in your use case here.
> The search engines won't support these new properties. What software are
> you targetting when you provide them?
>

I'm not targetting any particular software, I just want to make my data
available for whoever wants to use it. Sure, search engines are the #1 use
case today, but we should not design syntaxes with just that one type of
consumer in mind. If tomorrow Google wanted to provide facetted search on
type of publications, they could do it if the data is there (even if it's
not only using schema.org types). If the Firefox extension Zotero want to
pick these extra element of information beside the general schema.org types,
let them do it, there is no need to wait to have them standardized into
schema.org just because the syntax does not allow for types from multiple
vocabularies.

Steph.