Fwd: A versioning model for schema.org

Dan Brickley just submitted proposal for versioning of schema.org!

Besides that I would also recommend checking out issue I created
recently for *extending* schema.org
https://github.com/schemaorg/schemaorg/issues/284


-------- Forwarded Message --------
Subject: A versioning model for schema.org
Resent-Date: Thu, 29 Jan 2015 15:03:24 +0000
Resent-From: public-vocabs@w3.org
Date: Thu, 29 Jan 2015 15:02:54 +0000
From: Dan Brickley <danbri@google.com>
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.