different versions of classification systems and their concept URI's

[cbs bibliotheek]

In VocBench – Quick guide for classification maintainers I find this remark about classification versions and keeping concept uri's stable. Maybe someone can explain this more.

If we are sure that concepts across versions maintain the same exact notation, then it could be useful to put versions in the same project and use the same base URI for all concepts, so that the only difference between versions is whether a concept belongs to one or not (hierarchies could also be different, using a trick that can be explained in a separate document).

What about this "trick"? When can you keep concept uri's the same over different versions providing the notation and meaning does not change (but maybe the hierarchy does change)? What are your policies or ideas about this?

I incline to go for different concept URI's per scheme, but the notation could still be same.

Henk Laloli

[Armando Stellato]

Dear Henk,

 

the document, even though containing VocBench in the title, is related to a specific project managed by FAO (for which we provide hosting and support for the resources).

 

So, I’m just telling you is an educated guess based on my knowledge of VocBench and what I recall has being said in calls with them about their data policies. Moreover, this does not reflect any official versioning representation nor policy , but just a local policy adopted in the project (which, however, yes you can appreciate and use in your case if you want).

 

@Caterina....@fao.org is managing the project and is in this support group, so she can shed some more light on that, especially if my guess is wrong :P

 

In pag 61 of the document they say (I’m cutting other details and making the long story short) that they can keep different versions of the concepts using different URIs or that, in some cases, they may prefer to use the same URI and use schemes to tell in which versions a concept was available. In this sense, the dataset is the union of all concepts, existing, deprecated and (theoretically) removed, but through the membership of concepts to different schemes representing the versions, the status of a thesaurus in different time slots (the versions, exactly) can be kept.

 

However, the limitation here is that different versions of a thesaurus cannot be defined only by the presence or less of given concepts in the schemes representing the versions. Relationships matter, however, and these can also change with versions. Unfortunately, since relations are, mostly, binary relations described by simple triples, the triples, unless reified, cannot be bound to a specific version. So it is not possible to know which scheme (and, in this use of the schemes, which versions) a certain relation belong to. A typical example of a relation which may change over time is given by the skos:broader property. In order to concretely (and practically) use skos:broader, it is not possible to use a refied version (which, being reified, could be easily describe by further properties, such as the versions in which a certain relationship exists, but would be of non-practical management in general), rather different properties can be used, which ultimately mean the same thing, but represent different uses of the same property in different versions.

The “other document” mentioned in the above dataset is possibly something they never developed. In any case, the manual provides a short description for the mechanism:

 

http://vocbench.uniroma2.it/doc/user/projects_adm.jsf#project-groups_management

 

Kind Regards,

 

Armando

 

 

 

Pls notice also that VB supports versioning through a dedicated feature, which uses instead different repositories (one per version) that are all bound to a same project. The user can then move across versions as the client switches the currently selected repository to a different one representing another version. However, in their FAO case, this is different as, for some reasons, they wanted to have the same

 

 

 

--
You received this message because you are subscribed to the Google Groups "vocbench-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vocbench-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vocbench-user/197845dd-c463-4b32-b3e3-733645ecbce9n%40googlegroups.com.

[cbs bibliotheek]

Dear Armando,

thanks for your elaborate answer. Good that you focus on the question of changing relationships. Practically speaking, regarding changing relationships of concepts your case for using reified statements (or SKOS-XL) seems a good solution. Especially when focusing on aiding the user of the published schema. I will investigate this. I was already thinking about the need for additional metadata for external links like owl:sameAs.

Kind regards,

Henk

Op dinsdag 20 juli 2021 om 22:45:41 UTC+2 schreef stel...@uniroma2.it:

[Armando Stellato]

Dear Henk,

 

to clarify, we are not using reified statements (yes we do for SKOS-XL as that is the standard, or for reified notes in SKOS, as we provide an already configured custom form, and you can reify as many things you want with custom forms, but that’s another matter). We are using custom properties which can be defined under skos:broader and each property is a group-local property for definining a groups’ own hierarchy. We have then utilities in the data export page for transforming the custom broader property into the standard one.

 

Kind Regards,

 

Armando

 

To view this discussion on the web visit https://groups.google.com/d/msgid/vocbench-user/ac237494-6e83-408d-bdbd-669b9ef43930n%40googlegroups.com.