W3C home > Mailing lists > Public > public-vocabs@w3.org > January 2015

Re: A versioning model for schema.org

From: Simon Spero <sesuncedu@gmail.com>
Date: Thu, 29 Jan 2015 11:27:14 -0500
Message-ID: <CADE8KM4+1TpF-7RGy8t6g0J6BYtKcUHnW8j0S155F1OvvJqz+w@mail.gmail.com>
To: Dan Brickley <danbri@google.com>
Cc: W3C Web Schemas Task Force <public-vocabs@w3.org>

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

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.
Received on Thursday, 29 January 2015 16:27:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:49:38 UTC