search

gbv / cocoda

A web-based tool for creating mappings between knowledge organization systems.
https://coli-conc.gbv.de/cocoda/
MIT License
39 stars 5 forks source link

Assign URIs or other unique identifiers to local mappings #356

Closed stefandesu closed 5 years ago

stefandesu commented 5 years ago

Currently, local mappings are using the mapping content identifier when editing or deleting a mapping. This is suboptimal because two mappings can easily have the same identifier and I think currently Cocoda will only keep one of them in that case. We could assign URIs to local mappings, maybe something that also starts with https://coli-conc.gbv.de, or another identifier that uniquely identifies local mappings.

nichtich commented 5 years ago

Maybe use RFC 4122 UUID URIs?

stefandesu commented 5 years ago

jskos-server already uses this function to generate UUIDs, we could add that to Cocoda as well. What should the URI look like then? urn:uuid:xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx?

stefandesu commented 5 years ago

I just read through the comments on the gist and found out that the function creates collisions after a certain number of generated UUIDs. We can instead either use the uuid package (which should be very small and has no dependencies), or use a similar function from this StackOverflow thread that does not create collisions (I tested this one with the same test as the gist comment and didn't get any collisions even after generating 100,000,000 UUIDs).

Edit: uuid is very small as well, so maybe we should use that instead of a random method found on StackOverflow.

nichtich commented 5 years ago

Better take an established implementation of UUID both in cocoda and in jskos-server (possibly moved to jskos-tools)

stefandesu commented 5 years ago

I agree. We could add it to jskos-tools to make sure we use the same UUID implementation everywhere (although I'm a bit wary about adding another dependency to jskos-tools).

stefandesu commented 5 years ago

I'm still not sure about adding the dependency to jskos-tools. Adding it basically has the only advantage that we would make sure to use the same UUID implementation everywhere. At the same time, it has multiple disadvantages, like adding a dependency even though it is not needed everywhere where jskos-tools is used.

I also have a different question that is related to #357: If I save a mapping from one registry to another and that mapping already had a URI, but the new registry adds its own URI, should the old URI be kept in the identifier field? For #357, this would have the advantage that we could trace back the origin of the mapping, allowing something like my proposed synching functionality. It would also be in line with how we handle URIs and identifiers for schemes and concepts. This would not only have to be implemented here, but also in jskos-server and possibly in jskos-tools' identifier methods.

stefandesu commented 5 years ago

This is now implemented. Please test and report any issues, thanks! I'll close this issue tomorrow if we can't find anything.

stefandesu commented 5 years ago

uuid was only added to this project by the way, not to jskos-tools.