-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tag mappings with predefined categories #351
Comments
I like this. The implementation won't be trivial, but a system like this makes sense. Should annotations still exist and be extended with comments for discussion though? |
Yes, tags would be another kind of annotation in addition to votes an whatever turns out to be needed after discussion at our workshops
--
Jakob Voß via Android
|
Sounds good! |
A tagging annotation would look like this: {
"@context": "http://www.w3.org/ns/anno.jsonld",
"type": "Annotation",
"id": "https://coli-conc.gbv.de/api/annotations/...",
"target": "https://coli-conc.gbv.de/api/mappings/...",
"motivation": "tagging",
"body": "https://coli-conc.gbv.de/api/tags/foobar",
"creator": { ... },
"created": "..."
} The tag URI provided in "body" should resolve to a JSKOS concept (this could also be included in the annotation). |
Not sure what you mean by this, can you elaborate? By the looks of the URI, there should be a new "tags" entity in jskos-server for this. Or do you mean that those tag URIs are forwarded to concepts of a "Tags" concept scheme? Edit: Also, it should be |
The tag URI could also be different, we need no additional endpoint or URI schema. A tag set would just be a concept scheme that is also available from the same jskos server instance where annotations are stored. So a tagging annotation with Anyway, such feature is not planned for the near future unless required by actual users. |
A general tagging functionality of is not wanted but we will use tags to clarify reason for negative assesement (see #667). |
The current way to annotate mappings in KENOM with an additional N/A vocabulary is a hacky workaround that should be replaced in the long run. In addition or instead of to #172 support tagging of mappings with predefined categories such as "unclear", "discussion needed", "approved"...
The idea is the following (see tag groups in easyDB for a similar concept):
A tag group is a vocabulary of "tags". Tags should have properties such as color and icon (Unicode character?) to be recognizable. Examples: tag group "review status" with tags "suggested" and "approved" and tag group "bookmark" with tags "favorite" and "todo".
mapping registries (jskos-server, local mappings) can be configured which tag groups they support for which user groups
The text was updated successfully, but these errors were encountered: