Ensuring coverage of the change queries

[sinipessala]

For KOS developers, it is important to be sure that the developer has seen all the changes between two versions. However, when using SPARQL queries for listing different types of changes, it is possible that there are such changes that do not match the criteria of any of the queries. What solutions or queries would be suitable for ensuring that all of the changes are covered?

[jneubert]

Well - "all" may involve lots of changes. Here an example from TheSoz (which had minor changes in the last years - however, skosxl labels contribute a lot to the change numbers): If you filter for "insertion" or "deletion", you normally get values in the tenthousands or even hundredthousands of triples.

All changes could be grouped by concept (and for the sake of completeness perhaps by ConceptScheme/Collection). So technically, the task could be handled by listing all changed concepts, and linking for each such concept to a query similar to concept_deltas.rq, parametrized with the relevant versions, and extended to skosxl constructs. I suppose however that you more often than not would want to exclude some kinds of changes (e.g. changes which are global to the vocabulary, such as the addition of an automatically generated new property - for examples from STW see the code of the above query).

Anyway, a workflow based on a list of all changed concepts would not work well with a workflow based on lists for added concepts, deleted/deprecated concepts and other particular types of changes - you would come across the same concepts again and again. And I doubt that queries can be build which restrict the changes just to the "otherwise unidentified" ones.