- From: Dan Brickley <danbri@google.com>
- Date: Thu, 29 Jan 2015 15:02:54 +0000
- To: W3C Web Schemas Task Force <public-vocabs@w3.org>
This reflects a pile of discussions and constraints, as well as experience with foaf, dublin core etc. I've tried to keep it closer to requirements than implementation for now, though it is fairly implementation-oriented. Comments welcomed on the general direction. Dan --- A versioning model for schema.org. 1. For any instance document, it should have a simple way of indicating which version of schema(s) it is using, even while generating the same triples. While this is a minority interest, it is still a significant issue for some publishers particularly in public sector settings. -> propose a schemaVersion property https://github.com/schemaorg/schemaorg/issues/225 (this would allow us to avoid explicit version numbers in the main term identifiers, unless someone *really* wants them, for which see 2.c). 2a. For any schema.org term, there should be a machine readable history in terms of the different RDFS statements made about it over time. 2b. For each schema.org release, an frozen unchanging archival snapshot of the entire schema.org vocabulary should be available. This makes changes and evolution across the entire hierarchy visible. 2c. For applications that want to make assertions using specific unchanging versions of schema.org, there should be best practice advice on choice of namespace URIs. For example do they write * in RDFa, vocab="http://schema.org/versions/1.92/" typeof="Person" * in Microdata, itemtype="http://schema.org/versions/1.92/Person" * in JSON-LD, "@context": "http://schema.org/versions/1.92/" etc. -> dated dumps, e.g. published at these URLs, can address requirements 2a, 2b, 2c, and also provide URLs for requirement 1. 3. For each schema.org property at any point in time, the machine readable schemas should contain stability-related statements indicating - if this property supercedes another - if this property is considered stable, unstable, in review, archaic etc. - URLs for associated open issues e.g. to github - mappings to other linked data vocabularies, live or versioned, e.g. wikidata 4. It should be possible for other standards efforts to define normative reference to (relatively) stable pieces of schema.org, even while acknowledging that small changes in the meaning of one term can have practical impact for others terms elsewhere in the vocabulary. Examples for such normative references (e.g. use of version URLs, quoting of definitions etc.) would help with collaboration.
Received on Thursday, 29 January 2015 15:03:22 UTC