Skip to content
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

Closed
nichtich opened this issue May 16, 2019 · 7 comments
Closed

Tag mappings with predefined categories #351

nichtich opened this issue May 16, 2019 · 7 comments
Labels
feature Additional functionality question Further discussion needed workflow affects the mapping workflow
Milestone

Comments

@nichtich
Copy link
Member

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.
@nichtich nichtich added question Further discussion needed feature Additional functionality labels May 16, 2019
@nichtich nichtich added this to the 2.0.0 milestone May 16, 2019
@stefandesu
Copy link
Member

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
Copy link
Member Author

nichtich commented May 16, 2019 via email

@stefandesu
Copy link
Member

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
Copy link
Member Author

nichtich commented Aug 8, 2019

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

@nichtich nichtich added the workflow affects the mapping workflow label Aug 8, 2019
@stefandesu
Copy link
Member

stefandesu commented Aug 12, 2019

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
Copy link
Member Author

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
Copy link
Member Author

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

@nichtich nichtich closed this as not planned Won't fix, can't repro, duplicate, stale Mar 15, 2023
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
feature Additional functionality question Further discussion needed workflow affects the mapping workflow
Projects
None yet
Development

No branches or pull requests

2 participants