Allow versioning a conceptscheme

[koenedaele]

As requested by @mielvds

We would like to allow some basic aspects of versioning a conceptscheme. Currently we are still debating what is and isn't required.

Some general ideas:

• Version a scheme in it's entirety, not a single concept. If we were to version a concept, how would we version relations? If A related to B and we update A, does this update B as well and if so B is probably related to C and so on.
• Main need identified is to mark a scheme as a certain version and then allow editing of a draft version without replacing the already published version until the draft is approved in whole.
• Previous version should still be accessible, but the standard version should be the current version.

Some inspiration:

• I was pointed to a new effort called XKOS (https://ddialliance.org/Specification/XKOS/1.2/OWL/xkos.html#sem-props) and they have some best-practices in that regard: http://linked-statistics.github.io/xkos/xkos-best-practices.html#bp-evolution-series (from Add support for SKOS-XL #926)
• https://csiro-enviro-informatics.github.io/info-engineering/skos-bp.html (+ "Concept URIs are generally unversioned”.) (from Add support for SKOS-XL #926)
• https://blog.sparna.fr/2018/09/25/thesaurus-versions-of-scolomfr-skos/ and Use-Case : publishing successive versions of the same vocabulary NatLibFi/Skosmos#677 (from Add support for SKOS-XL #926)

[mielvds]

I got some more input:

1. skos-history

Some years ago, Joachim Neubert worked on [skos-history]:

"This project tries to take advantage of the regular structure of SKOS
files to make these questions answerable for both non-geeky humans and
machines. To this end, an ontology/application profile, a set of
processing practices and supporting code are developed."

The repo also contains a list of use case. I think this approach is at
least used for the [STW].

2. owl:deprecated and dct:isReplacedBy + git

I am not familiar with skos-history, and we have been using a simpler
approach in the context of the – small to medium-sized – controlled
vocabularies we are maintaining at KIM (see [list]).

• We are git/GitHub for versioning and coordinating the development
• We are writing vocabs in Turtle syntax by hand.
• In one case we are generating SKOS Turtle from a CSV provided by
  Destatis and have started to format the SKOS-Turtle as such that
  tracking with line-based versioning in git is optimized.
• We use owl:deprecated and – if applicable – dct:isReplacedBy if a
  concept is removed while keeping the hierarchical relationships
  (skos:broader/narrower)

We are using SkoHub Vocabs for publishing the vocabs with an automatic
workflow triggered by git commits, see the [SkoHub pages] post when you
are interested in trying it out. You might also use different git
branches to publish multiple versions of a vocab, see [skohub-vocabs#43].

3. Publishing versions with SKOSMOS

See [blog post] and [issue].

All the best
Adrian

[pad] https://pad.lobid.org/s/metadaten-barcamp-2024-historizit%C3%A4t#
[skos-history] https://github.com/jneubert/skos-history
[STW] https://www.zbw.eu/stw/version/latest/about.en.html
[list]
https://github.com/search?q=topic%3Askos+org%3Adini-ag-kim&type=Repositories
[SkoHub pages] https://blog.skohub.io/2024-03-21-skohub-pages/
[skohub-vocabs#43] skohub-io/skohub-vocabs#43
[blog post]
https://blog.sparna.fr/2018/09/25/thesaurus-versions-of-scolomfr-skos/
[issue] NatLibFi/Skosmos#677