Tag mappings with predefined categories

nichtich commented 5 years ago

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

a mapping can only be assigned one tag for each group
individual tags (e.g. "approved") may also be reserved for selected user groups
individual tags (e.g. "suggested") may also be marked as default to be assigned to every newly created mapping
indivudual tags may also be marked as "sticky" so they cannot be removed.

stefandesu commented 5 years ago

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?

nichtich commented 5 years ago

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

stefandesu commented 5 years ago

Yes, tags would be another kind of annotation in addition to votes an whatever turns out to be needed after discussion at our workshops

Sounds good!

nichtich commented 5 years ago

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).

stefandesu commented 5 years ago

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 bodyValue, right?

nichtich commented 5 years ago

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 "body": "http://example.org/foo" references a tag that can be queried via /data endpoint and links to its tag group via inScheme. A tag group would just be another vocabulary served by the same jskos-server instance.

Anyway, such feature is not planned for the near future unless required by actual users.

nichtich commented 1 year ago

A general tagging functionality of is not wanted but we will use tags to clarify reason for negative assesement (see #667).

gbv / cocoda

Tag mappings with predefined categories #351