Feature wishlist

[mielvds]

Hello! meemoo is interested in maybe adopting atramhasis and contributing to the code. I'm having a chat with @koenedaele next week, but I already wanted to list some of the desired features:

• simple user management with access rights and roles
• integration with LDAP or SAML
• creating and importing concept schemes through the UI
• the possiblity to browse, edit and delete existing concept schemes in the UI
• simple collaborative editing with adding, accepting and rejecting suggestions and/or comments
• simple version management with published releases and drafts
• deploy to RDF triple store

[koenedaele]

Hi, a few quick answers:

Hello! meemoo is interested in maybe adopting atramhasis and contributing to the code. I'm having a chat with @koenedaele next week, but I already wanted to list some of the desired features:

• simple user management with access rights and roles
• integration with LDAP or SAML

We use ACM/IDM from our own authentication plugin. The framework Atramhasis was built upon, https://trypyramid.com/, is very configurable that way. See https://docs.pylonsproject.org/projects/pyramid/en/2.0-branch/narr/security.html for the full docs. Should be integrateable with just about any authentication source such as LDAP or SAML. There are open source plugins out there that do similar things.

• creating and importing concept schemes through the UI

Currently it's not possible to create a conceptschem through the UI since there is some programmatic configuration involed. Once created, it is possible to edit the metadata about the conceptscheme though. Importing of concepts is possible on a one by one basis, but not for a full conceptscheme. Importing entire conceptschemes from SKOS files is possible through the CLI.

Creating conceptschemes through the UI has been discussed once or twice, so there's certainly some interest in that.

• the possiblity to browse, edit and delete existing concept schemes in the UI.

Browsing and editing conceptschemes and all concepts in them is possible. Deleting individual concepts from a conceptscheme is possible from the UI. Deleting an entire conceptscheme with all its concepts in one command through the UI is not possible.

• simple collaborative editing with adding, accepting and rejecting suggestions and/or comments

Adding concepts and collections is possible. Editing them by adding labels, notes and relations is possible.
There is no mechanism for suggestions and rejecting or accepting them. Currently this is handled out-of-band through face-to-face communications and word docs and such. It's not a feature we are against, but finding a good workflow seems difficult.

• simple version management with published releases and drafts

Currently we do not have this, but we do have requirements like this. Unfortunately, this is not at all present in the SKOS standard, so this would be a custom extension that makes interoperability with other SKOS vocabulary systems more complicated. But it's something we would certainly be interested in.

• deploy to RDF triple store

We've intergrated nightly datadumps in rdfxml, turtle and hdt. More would be possible as long as the format is supported by Python RDFlib. These datadumps are also used to setup an LDF server.

[koenedaele]

Based on our talk, #707 would be helpful and a quick win.

[mielvds]

@koenedaele I was thinking a bit more on the version management aspect, and there are multiple sides to this:

• the PAV vocab can be used to add version information to SKOS: http://pav-ontology.github.io/pav/index.html
• would you be able to connect a skosprovider with a git repo and offload data versioning to git?
• what can we use from https://www.w3.org/wiki/SkosDev/SkosCore/SchemeVersioning?

[koenedaele]

I'll have a look at those links. Have you used the PAV vocab before? How stable is it?

would you be able to connect a skosprovider with a git repo and offload data versioning to git?

Could you list the possible use cases you see in this? Why we would want this, who needs it and such. Is it mostly writing a specific version of a CS to GIT as a sort of archive/backup, or do we actively need to power the Atramhasis REST services through GIT?
I assume some things should be possible, since we already have a skosprovider_rdf, so it's a matter of storing those RDF files in GIT and reading them again.

[mielvds]

I'm probably getting ahead of myself here. The features in order of importance are:

• adding a version number/URI/both to a CS (so something like PAV)
• deprecate concepts
• being able to freeze a CS in time
• link/navigate to next/prev versions
• integrate with Git (indeed, something like a continuous sync in the skosprovider_rdf, but that's not very important atm)