Functionality review

[koenedaele]

After running the demo and playing around with the tool a bit, here my review in addition to related opened issues (see above).

Overall I found the tool intuitive to use and did not encounter any issues. I browsed existing concept schemes and edited existing concepts via the admin interface. Based on these example scenarios, I would consider that the tool has a state-of-the-art web interface. For example, when opening the admin menu on the right the main window greys out which makes clear that the focus is now on the menu. Content of a concept scheme in the menu on the right is also loaded on-demand which makes sense for large concept schemes and which I consider also a common functionality.

In the following I will only focus on a few minor things.

• I noticed that the RDF representation uses the datatype integer for dcterms:identifier. According to the DublinCore specification this is not wrong as any literal can be used. However, it feels un-intuitive as I think doing arithmetic with identifiers is not a use case and considering also that identifiers might contain letters. But I have seen, that there are already issues regarding that, and that this might change in future versions.
  The provided dump_rdf commandline tool comes in very handy and it is a nice addition, that it also offers the possibility to output HDT files.
• Some URIs of concepts are URNs, for example concepts created via imports from a skosprovider. These URNs are highlighted as clickable URIs and users not aware of the principles behind the SemanticWeb might get confused if such a URN is not resolvable. Would it make sense to render URNs as text? Or alternatively have a redirect service to a permanent URI in the system?
• After adding a new concept to a concept scheme, I noticed that the list of concepts on the right was not updated. A reload was necessary. This is a minor issue, but I would have expected that some sort of event gets triggered and the list will be updated with the newly added concept. An impatient user might create a concept several times or may contact the support for such kind of things.
• I never used the tool cookiecutter before, but it seemed to work. However, the small issues I encountered during setting up the demo because of an outdated version of pip and setuptools (see linked issue above) could have been avoided with a docker demo. I have seen that the documentation lists such a method, but also with a warning that it was written for a different version and might not work anymore, which why I did not try it. Docker is widely used and I think it would be an added value if the docker setup would be updated and made available also for the current version of the tool.

One rather odd thing is, that I was not able to create new concept scheme via the UI. However, this was also not claimed in the software paper and the documentation clearly says that concept schemes have to be created via different interfaces. Hence the following paragraph is just some feedback and my thoughts regarding this.

I was wondering, is the addition of the feature "create concept scheme from the UI" foreseen in the future? The creation of new concept schemes seems like a very basic functionality to me, especially when starting to use the tool.
Thinking further in this direction: In the cited paper from 2017, one lesson learned was that a thesaurus manager was appointed for the use case of Flanders Heritage. This makes very much sense. Picking up again the different types of possible users from my software paper review above, I think such a thesaurus manager is an interesting role to consider for the future. A thesaurus manager is likely a domain expert and may require a UI. I can imagine a use case where only a user with the role thesaurus manager can create new concept schemes and is the only one with editing rights, or could grant further editing rights to other users for the thesauri (concept schemes) s/he created.
From an implementation point of view, this would of course require the addition of roles which also may depend on the used authentication/authorization mechanism.

I will provide a different comment for the review of the documentation early next week.

Originally posted by @SvenLieber in openjournals/joss-reviews#5040 (comment)

[koenedaele]

• I noticed that the RDF representation uses the datatype integer for dcterms:identifier. According to the DublinCore specification this is not wrong as any literal can be used. However, it feels un-intuitive as I think doing arithmetic with identifiers is not a use case and considering also that identifiers might contain letters. But I have seen, that there are already issues regarding that, and that this might change in future versions.
  The provided dump_rdf commandline tool comes in very handy and it is a nice addition, that it also offers the possibility to output HDT files.

True. Python RDFlib automatically adds this based on the internal datatype of the id. However, we've changed the internal datatype from integer to string to be able to handle thesauri with non-numeric id's. So, this will be changed in version 2.

• Some URIs of concepts are URNs, for example concepts created via imports from a skosprovider. These URNs are highlighted as clickable URIs and users not aware of the principles behind the SemanticWeb might get confused if such a URN is not resolvable. Would it make sense to render URNs as text? Or alternatively have a redirect service to a permanent URI in the system?

The URN's are an example of something that's technically possible, but not actually practical in use. I don't know any real-life RDF vocab that actually uses URN's. Conceptually Atramhasis allows you to configure URI's or URN's, but does not handle redirection since a lot of organisations already have some form of handler. We've also provided a simple handler (https://github.com/OnroerendErfgoed/urihandler) for those who do not have one. Rendering URN's a text seems like a simple and cheap solution, so I'll add a feature request for that.

• After adding a new concept to a concept scheme, I noticed that the list of concepts on the right was not updated. A reload was necessary. This is a minor issue, but I would have expected that some sort of event gets triggered and the list will be updated with the newly added concept. An impatient user might create a concept several times or may contact the support for such kind of things.

Thank you. Will be fixed in #763

• I never used the tool cookiecutter before, but it seemed to work. However, the small issues I encountered during setting up the demo because of an outdated version of pip and setuptools (see linked issue above) could have been avoided with a docker demo. I have seen that the documentation lists such a method, but also with a warning that it was written for a different version and might not work anymore, which why I did not try it. Docker is widely used and I think it would be an added value if the docker setup would be updated and made available also for the current version of the tool.

True. It's not a technology we use, but someone was offering to contribute to a Docker image, so this might return.

One rather odd thing is, that I was not able to create new concept scheme via the UI. However, this was also not claimed in the software paper and the documentation clearly says that concept schemes have to be created via different interfaces. Hence the following paragraph is just some feedback and my thoughts regarding this.

I was wondering, is the addition of the feature "create concept scheme from the UI" foreseen in the future? The creation of new concept schemes seems like a very basic functionality to me, especially when starting to use the tool. Thinking further in this direction: In the cited paper from 2017, one lesson learned was that a thesaurus manager was appointed for the use case of Flanders Heritage. This makes very much sense. Picking up again the different types of possible users from my software paper review above, I think such a thesaurus manager is an interesting role to consider for the future. A thesaurus manager is likely a domain expert and may require a UI. I can imagine a use case where only a user with the role thesaurus manager can create new concept schemes and is the only one with editing rights, or could grant further editing rights to other users for the thesauri (concept schemes) s/he created. From an implementation point of view, this would of course require the addition of roles which also may depend on the used authentication/authorization mechanism.

True. So far, this has been intentional. While adding a conceptscheme seems trivial, it's actually an important decision and needs some well thought out choices. A decision needs to be made on what URI's to generate and how to handle them. Quite often it's important to know how the conceptscheme will be intergrated within another application. So far, we felt that it was better to do this through a bit of fairly trivial configuration. However, we will add this feature in version 2 since there's a lot of demand for it and we have some experience now with the kind of choices that are commonly made when configuring a CS, so we have identified a path forward for this.

Adding a new CS will require a special permission. The underlying framework allows translating this to roles in whatever way the implementor desires. So, it's possible to have a thesaurus admin and a thesaurus editor or to combine this role.

[koenedaele]

Thank you for the detailed review!