|Title:||SKOS in Two Parts - Part 1: Change Tracking in Knowledge Organization Systems with skos-history|
In the past seven years, SKOS has become a widely recognized and used common interchange format for thesauri, classifications, and other types of vocabularies. This has opened a huge opportunity for the development of generic tools and methods that should apply to all vocabularies that can be expressed in SKOS. While expensive, proprietary or custom-developed solutions aimed at one particular thesaurus or classification have been dominant, now more and more open source tools are being created to deal with various aspects of vocabulary management.
When a new version of a vocabulary is published, users want to know "What’s new?" and "What has changed?" Vocabulary managers had differing strategies to answer these questions - relying on internal logs of the vocabulary management system or the intellectual collection of changes deemed relevant. These methods generally are not available to third parties using a vocabulary, or for example are trying to keep vocabulary mappings up to date.
Having vocabularies published in SKOS as RDF triples has changed this situation: Vocabularies can be compared algorithmically, and deltas between versions can be computed. This data can be loaded into a version store, and evaluated by SPARQL queries. Therefore, the published versions alone are sufficient to get the differences.
The webinar will explain how you can create a version store, how skos-history interlinks versions and deltas, and how queries can get a grip on added or removed concepts, on changed notations, or on merges and splits of concepts. We will show how aggregated change information about a concept scheme can be obtained, and how the complete change history of a single concept across multiple versions can be traced. Finally, you will learn how you can adapt skos-history queries to the features of a particular concept scheme in which you are interested.
Skill level: Intermediate. A working knowledge of SKOS and a basic knowledge of triple stores and SPARQL queries are presumed.