- From: Adrian Pohl <pohl@hbz-nrw.de>
- Date: Mon, 2 Dec 2024 15:45:35 +0100
- To: public-esw-thes@w3.org
Hi Miel, I second Renato's point about not putting any version information in concept or concept scheme URIs, afaik, this has never been a good idea. In my view there are neither consensus nor even some emerging community patterns on versioning SKOS. It would be great to have an overview and/or some recommentations somewhere. Here are a few more resources about versioning SKOS, some of them I took from a recent session in the "Metadaten-BarCamp" (see [pad] in German). 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] https://github.com/skohub-io/skohub-vocabs/issues/43 [blog post] https://blog.sparna.fr/2018/09/25/thesaurus-versions-of-scolomfr-skos/ [issue] https://github.com/NatLibFi/Skosmos/issues/677 On 11/22/24 00:48, Renato Iannella wrote: > Hi Miel, > > Here are some guidelines: https://csiro-enviro-informatics.github.io/ > info-engineering/skos-bp.html <https://csiro-enviro- > informatics.github.io/info-engineering/skos-bp.html> > > I think an important point is "Concept URIs are generally unversioned”. > > > Cheers - Renato > >> On 21 Nov 2024, at 19:15, Miel Vander Sande >> <miel.vandersande@meemoo.be> wrote: >> >> >> Hello all, >> >> I was wondering if any of you has some experience with maintaining >> multiple versions of a SKOS Concept Scheme and its Concepts. >> Some specific guidance I'm looking for: >> - how can you properly attach a version number? >> - is there any consensus or vocabulary on how to describe versioning? >> - how to deal with deprecation? >> - how can users migrate from version a to version b? >> - how to properly version concept and concept scheme URIs, let alone >> the links between them? >> - ... >> >> For each of these, I can think of some solution, but I was wondering >> if anyone has faced the same questions and can share how you solved >> them? Any examples or best-practices would be very welcome. >> >> Best, >> >> >> -- >> <https://meemoo.be/nl> Miel Vander Sande >> Data Architect >> >> >> meemoo vzw | Ham 175, 9000 Gent | https://www.meemoo.be/ <https:// >> meemoo.be/nl> >> t +32 9 298 05 01 | m +32 496 83 21 29 >> >> App Banner Image <https://kennisbank.meemoo.be/? >> utm_campaign=signature&utm_source=WiseStamp&utm_medium=email> >> >> __tpx__ >
Received on Monday, 2 December 2024 14:46:10 UTC