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

Re: Draft Note for HTML WG

From: Dan Brickley <danbri@danbri.org>
Date: Mon, 14 Nov 2011 12:18:32 +0100
Message-ID: <CAFNgM+Z8EXVNuwrrDD3jgSYcEJ-kuxBc9g7RFZr_fyFbmZ+6JQ@mail.gmail.com>
To: Jeni Tennison <jeni@jenitennison.com>
Cc: Ivan Herman <ivan@w3.org>, HTML Data Task Force WG <public-html-data-tf@w3.org>
On 14 November 2011 11:59, Jeni Tennison <jeni@jenitennison.com> wrote:
> On 14 Nov 2011, at 10:44, Dan Brickley wrote:
>> It certainly wouldn't hurt to have a more carefully documented use
>> case for multiple-types.
> I don't think there is a persuasive one for microdata, particularly as the pattern of use for microdata at the moment is to roll everything into the schema.org vocabulary. From what I can tell, Hixie doesn't even believe that the vocabularies in the WHATWG microdata spec will actually be published or consumed by anyone. (If he did then I'd hope that [1] was sufficient documentation of a use case.)


> If schema.org recommended extending the set of types that they support not through string concatenation but by publishers minting their own vocabularies, we might have a different picture. Of course, since microdata wouldn't be able to support that, we're kind of in a chicken-and-egg situation! :)

We announced Schema.org's support for the RDFa Lite view of RDFa on friday.
- http://blog.schema.org/2011/11/using-rdfa-11-lite-with-schemaorg.html -
It got a lot of positive responses on the Twitter I must say. Now this
doesn't mean that all Schema.org-supporting search engines will gain
RDFa Lite powers overnight, of course. But I think the direction is
very encouraging. So RDFa Lite is a path for those who want to publish
multiple types and vocabularies.

A specific example I'm looking at now is TV/Radio markup;  see
http://www.w3.org/wiki/TVRadioSchema and
http://www.w3.org/wiki/SchemaDotOrgTV ... the BBC folk are already
publishing a lot of rich RDF, including RDFa, and Schema.org doesn't
let them say everything they want to. Double-typing and  possibility
of extra properties in other namespaces soften the tradeoffs a bit as
they decide whether to adopt schema.org...

As I mentioned in the blog comments in the RDFa Lite / Schema.org
post, and speaking personally... I don't think it inconceivable(*)
that Schema.org could evolve into a documentation centre that also
described some common HTML-data idioms using other popular namespaces.
This is most likely in the case of large enumerations, and in fact
happening already in a very basic way. So you see in
http://schema.org/JobPosting a property occupationalCategory, which
informally cites the taxonomy at
http://www.onetcenter.org/taxonomy.html (when ESCO ships, we'll likely
cite that too). Here's the markup example:

<strong>Occupational Category:</strong> <span
itemprop="occupationalCategory">15-1132.00 Software Developers,

...from an RDF perspective this isn't very joined up data yet; but it
does show a natural scoping limit to Schema.org. We can't copy and
paste all such schemes into one big Schema. What we can do is
encourage those controlled vocabularies to publish (in SKOS/RDFa
rather than PDF or Excel?) and document e.g. how '15-1132.00 Software
Developers' as a string relates to entries in that dataset, and/or how
they could be cited by URL instead. If Schema.org can grow towards
such a documentation centre role, i.e. as a hub for publishers and
consumers of this data, then it might be a natural step towards also
documenting medium and small-sized vocabularies too. As ever, that
doesn't mean all search engines will support everything. So I think
we'll start with the large controlled vocabs
(wikipedia/freebase/dbpedia/wikidata, SKOS) while also collecting
mappings to the other widely used RDF vocabs. If RDFa parsers did
something useful with such mappings, that might help move things along



(*) is that a pecularly Britis English-ish formulation? :)
Received on Monday, 14 November 2011 11:19:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:08:25 UTC