- From: Dan Brickley <danbri@danbri.org>
- Date: Mon, 14 Nov 2011 12:18:32 +0100
- 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.) Ok. > 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, Application</span> ...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 too... cheers, Dan (*) is that a pecularly Britis English-ish formulation? :)
Received on Monday, 14 November 2011 11:19:10 UTC