Re: A versioning model for schema.org

Hi,

As part of the management of vocabularies, we use the *dcterms:provenance*
property [1] to encode the changes that were implemented to a vocabulary as
a whole. We adopted this approach as the PROV(enance) ontology seemed to
over-complicated and created more triples than we needed to provided
provenance information.

Kind regards,

Quentin


[1] http://dublincore.org/documents/dcmi-terms/#terms-provenance

On 29 January 2015 at 11:03, jean-delahousse <delahousse.jean@gmail.com>
wrote:

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