sshoc-marketplace-frontend issueshttps://gitlab.gwdg.de/sshoc/sshoc-marketplace-frontend/-/issues2022-11-18T14:58:49Zhttps://gitlab.gwdg.de/sshoc/sshoc-marketplace-frontend/-/issues/126map entitiy properties to schema.org things2022-11-18T14:58:49ZStefan Probstmap entitiy properties to schema.org thingswe should have a mapping of marketplace entities (and their properties) to schema.org. we can then include jsonld metadata on the item detail pages.
i have started with MPDataset, help apprectiated:
| Dataset | [dataset](https://schema...we should have a mapping of marketplace entities (and their properties) to schema.org. we can then include jsonld metadata on the item detail pages.
i have started with MPDataset, help apprectiated:
| Dataset | [dataset](https://schema.org/Dataset) |
| ------- | -------- |
| label | headline |
| description | abstract |
| description | description |
| accessibleAt | url |
| ??? | includedInDataCatalog |
| properties: keyword | about |
| licenses: label | license |
| version | version |
| contributor: actor.name | contributor |
| dateCreated | dateCreated |
| dateLastUpdated | dateModified |
| properties: language | inLanguage |Now or neverAlexander KönigAlexander Könighttps://gitlab.gwdg.de/sshoc/sshoc-marketplace-frontend/-/issues/88sort actor and concept combobox values alphabetically2022-10-27T11:13:37ZMatej Durcosort actor and concept combobox values alphabeticallyCurrently with a longer vocabulary, user in edit form has to know what to start typing to get a suggestions.
There has to be a way to see full list of vocabularies
- in minimal case (vocabulary specific) link to https://vocabs.sshopenclo...Currently with a longer vocabulary, user in edit form has to know what to start typing to get a suggestions.
There has to be a way to see full list of vocabularies
- in minimal case (vocabulary specific) link to https://vocabs.sshopencloud.eu/vocabularies/en/ (or whatever they are published, e.g. TaDiRAH in https://vocabs.dariah.eu/tadirah/en/)
- or some listing of the whole vocabulary as listed by the API.
Ideas how to implement?
(notify: @klaus.illmayer , @lbarbot @matej.durcoNow or neverStefan ProbstStefan Probsthttps://gitlab.gwdg.de/sshoc/sshoc-marketplace-frontend/-/issues/84Highlight changes in fields of suggested items2022-07-22T09:46:35ZKlaus IllmayerHighlight changes in fields of suggested itemsFirst of all: the notion of fields in this issue includes attributes (like the description of an item) as well as dynamic properties.
## Problem description
Contributors suggest a new version of an item. Such suggestions are approved b...First of all: the notion of fields in this issue includes attributes (like the description of an item) as well as dynamic properties.
## Problem description
Contributors suggest a new version of an item. Such suggestions are approved by moderators. For this we have the curation dashboard `Items to moderate` where all suggested versions are collected. By editing and publishing such a suggestion this version becomes the new approved version. Curators scroll through the edit form of the suggested item and look, if this item can be approved.
Now the problem: there is currently no (visual) clue which fields changed compared to the current approved item. Therefore it is not easy for moderators to spot, which fields to look for moderation. It would be very helpful, if there is something like a visual highlighting (like an icon and/or a background color) for all fields that are different to the current approved item. Moderators can then focus on this changes which would simplify the approval workflow.
Current workaround: Open a second browser tab with the current approved item and compare it with the content of the suggested version in the first browser tab. This needs a very focused approach and is by no means error-free.
## Solution discussion
I've had already a discussion with @stefan.probst on this and a further discussion round with @lbarbot and @buddenbohm, summing up the current information.
Frontend solution: Finding a good and easy solution is not that easy if frontend should solve this alone. First of all we do not have an UX/design proposal that we could use. Questions are:
* what is a usability-conform way to show the differences between two fields (color alone - which color? - is not accessibility conform)?
* how to show deleted fields? (more easier: how to highlight added fields)
* to which detail should changes of fields be shown: have a diff of a text field (showing which letters where added/deleted/changed)
* how to process the API results of the items to be compared: there is probably no coherent way to do this automatically, as we do have different field structures based on the difference between attributes/properties, the different data types (a concept is expressed in a very different way as a string field), foreign keys to e.g. actors, sources identified by id
* would that imply a way to revert the value of a field by clicking on a button?
* connected to the last point: should changes by moderators be shown in a different highlighting?
* what should be compared when there are more then one suggestions of an item?
Backend solution: It could be possible that backend does such comparision and delivers a meta-information on changed fields at an suggested item. Disadvantage: coding effort at backend, solves only some questions for frontend.
Curation notebooks solution: The easiest way could be to delegate comparisions between versions of an item to a notebook, which could GET the different versions of an item from the API, do a [diff](https://en.wikipedia.org/wiki/Diff) and show the result. Disadvantage: no integration in the curation dashboard, moderators need to be sensitive and aware about the curation notebook.
## Solution proposal
The mentioned discussions already gave some proposals:
* It is expected that the highlighting of changes is part of the frontend/curation dashboard.
* Comparision should be always based on the current approved item. If there are more suggested versions it is up to curators to decide which to take. The highlighting of a suggested version should always and only be compared against the current approved item (if there is no approved item available, this could be expressed in an information message).
* Highlighting should be very basic, details are not necessary, it is only about telling curators that one field is different to the one of the current approved item (not telling what is different).
* UX/Design proposal is necessary, could @wytrazek create a mockup for this?
There is also another discussion about this issue, where there is a proposal to have the two versions next to it in one screen, allowing moderators to approve/reject changes. It is also mentioned in this disucssion, that this may be the best solution but also the most tricky one to implement. Thus I propose to go with the simplier version (only highlighting changes) and leave it up to the moderators to decide if they approve all changes. If moderators identify revisable changes, then further inquiry should be done manually (giving a workflow document on how to do this: looking for the current approved item in a second tab and comparing it).
I also think that a solution for this issue is not necessary for the release in December but it should be solved until the end of the project when a new curation team takes over.
Summing up:
* @lbarbot @matej.durco @edward.gray @buddenbohm Please give advise about how sophisticated this issue should be solved
* Based on this a mockup should be created, keeping in mind UX/design issues
* Afterwards @stefan.probst can implement the proposals of the mockupNow or neverStefan ProbstStefan Probst