-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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: