Enumerations, Wikidata and subclasses ... oh my!
Rather than revisit relevant earlier threads regarding two posts that have just been made to public-vocabs, I'd to quickly note them and link to them under this new heading, as the two are closely related.Another example of Wikidata + schema.org for type enumerationshttp://bit.ly/1mAbKqM
A really excellent explanation from +Dan Brickley
about what Wikidata is, what its data model looks like, and how it might be incorporated into schema.org
- especially as is supports the creation of "descriptions that draw on 'types' from Wikidata alongside matching broader types from schema.org
." In other words, as an approach to incorporating required missing 'subclasses' into schema.org
without endlessly extending the vocabulary.
Dan provides an explicit, annotated RDFa example of how this might work. This really sets the stage for a viable, community-based process of reliably extending schema.org
in ways that data consumers can readily understand, without extending the schema.org
"The Wikidata machinery (and hopefully community process!) should also make it fairly easy to add properties linking these type-like entities to other types such as at schema.org
, so that the wider community can keep collective notes on the relationships between the type-like entitites Q1370598 and Q199451 in Wikidata and schema.org
's 'PlaceOfWorship' type.'"
What I really like about this approach is one gets the benefit of being able to extend schema.org
at the publisher level (by simply encoding these linkages), and doing so by leaning on something (Wikidata) whose raison d'être
to extend vocabularies but "to create a common data repository" - an independently robust initiative.The YourSports vocabulary extensionhttp://bit.ly/1grQKLg+Jarno van Driel
takes the bull by the horns here, throwing his weight behind the approach suggested by +Gregg Kellogg
with "the use of enumerations over specific sub-classes," but bemoaning the lack of direction provided both in terms of which sites to use for such enumerations, and alluding to the confusion surrounding extension mechanisms.
As the two posts address the growth and utility of schema.org
they're closely related.
Dan explicitly acknowledges the concern Jarno and I have raised regarding the ability of schema.org-consuming search engines to understand these external data sources, but "for now I'd like to concentrate on making sure the representational machinery matches up." Getting that representational machinery right is obviously a core task, and yes, is a reasonable precursor to domain determinations, so I think it's a really positive step to address this.
And I really feel like we're beginning the see the benefit of hashing things out in regard to extensions, if not actually the positive development of schema.org
in general, however much the discussion is sometimes cantankerous. :) #schemaorg #wikidata #schema