Create and save into concordances, assign mappings to a concordances

[stefandesu]

This should eventually be possible in Cocoda. Things to consider:

• Who can write into which concordance? (Only creator? Can others be given the rights?)
• jskos-server would need to be adjusted that those mappings are not deleted on reimport of a concordances.

...

[nichtich]

There is a workaround using comments (#453). One gbv/cocoda#406 is available, entirely remove mapping comments.

[stefandesu]

Is this something that needs to be discussed with the workflow group, or are the requirements for this feature relatively clear? By the way, mapping comments were already removed.

[nichtich]

This should be discussed on the meeting at March 30th.

[nichtich]

Saving a mapping into a concordance is basically saving a mapping with field partOf referencing an existing concordance (see #99 to manage concordance metadata). The rest is

• issues of consistency
  • should a mapping only be allowed to be part of one concordance at most? (I think so for simplicity)
  • fromScheme and toScheme of a mapping must match the same fields of its concordance
• issues of authentification: who should be allowed to write mappings into concordances (and to remove mappings from)?
  • identies listed in creator should always be allowed
  • plus identies listed in contributor (so the creator could add contributors via editing concordance metadata)
  • we may later want user groups but this is not needed to start with
  • open question: what if a mapping with author X is part of a concordance but X is not allowed to edit into this concordance (e.g. happened during import or the author was removed from contributor)? - should the author be allowed to delete the mapping and to remove the mapping from the concordance? Otherwise X cannot edit the mapping anymore in this case (actually this may be a wanted feature)
• issues of workflow and user interface design: how to select whether/when to assign mappings to concordances. This issues are not part of jskos-server.

[stefandesu]

I agree with all your points in the last comment and I personally think we could already start to implement this.

• open question: what if a mapping with author X is part of a concordance but X is not allowed to edit into this concordance (e.g. happened during import or the author was removed from contributor)? - should the author be allowed to delete the mapping and to remove the mapping from the concordance? Otherwise X cannot edit the mapping anymore in this case (actually this may be a wanted feature)

My suggestion would be to disallow editing or deleting the mapping in this case. Adding this functionality later would not be a breaking change in my opinion, so better to do it this way around for now.

[stefandesu]

I'm closing this issue in favor of #99 since we've been discussion the same things over there...