W3C home > Mailing lists > Public > public-html-data-tf@w3.org > October 2011

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

From: Stéphane Corlosquet <scorlosquet@gmail.com>
Date: Tue, 18 Oct 2011 13:26:36 -0400
Message-ID: <CAGR+nnFz5YBW1=1UFvT4tYYrAt34=BJzJmDPvqE8y9ZNXAb8PQ@mail.gmail.com>
To: Martin Hepp <martin.hepp@ebusiness-unibw.org>
Cc: Jeni Tennison <jeni@jenitennison.com>, public-html-data-tf@w3.org
Hi Martin, all,

On Sat, Oct 15, 2011 at 2:49 PM, Martin Hepp <
martin.hepp@ebusiness-unibw.org> wrote:

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

With this method, the secondary types of a microdata item could easily be
merged with the primary types in RDF, and I'm sure that's something Gregg
would be happy to add to the microdata > RDF conversion steps. But how about
the microdata DOM API? Ok, people can start using this convention in their
HTML and it doesn't depend on an immediate solution in the Microdata spec,
but those consuming microdata will need to handle the secondary types in
their code, since these types won't be exposed via document.getItems(). I'm
not aware of any microdata method to retrieve items based on the value of a
property? Is there a better solution than calling document.getItems();, and
do a for loop to extract the items matching a given secondary type? Could
these secondary maybe supported by getItems() to avoid developers to special
case this?

Steph.


>
> 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/Thingwithout 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 Tuesday, 18 October 2011 17:27:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 18 October 2011 17:27:18 GMT