Re: A versioning model for schema.org

Thoughts:

Will superseded terms always have explicit equivalentBlah assertions? Are
they implicitly deprecated? Will they have specified invalidation times?

Is there a need for some sort of term-specific (in)compatibility
annotations?
If a term's meaning is changed so as to be incompatible with the previous
meaning, but only in certain cases, should those be specified in a machine
readable way?

If a term is split so that there are several successor terms, how should
this be represented ? Should there be a distinction between a covering
division that excludes part of the previous meaning?

If  terms are partially merged, how might this be indicated?

2c may be problematic; if a term is backwards/forwards compatible, then
maybe  its IRI shouldn't change?

It would seem simpler to have the using document specify the versioned
schema ontology IRI (in a meta header?)

This beat is, this beat is, this beat is diachronic.

Simon
On Jan 29, 2015 10:05 AM, "Dan Brickley" <danbri@google.com> wrote:

> 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.
>
>