Re: A versioning model for schema.org

Thoughts:

PROV(enance) ontology could be very useful to describe the changes and link
them to  related "issues" as well as formal decision which validate the
change.

Best regards

Le Thu Jan 29 2015 at 17:30:23, Simon Spero <sesuncedu@gmail.com> a écrit :

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