Ticket #924 (new Enhancement) — at Version 2

Opened 5 years ago

Last modified 5 years ago

Collaborative authoring of public data in private views

Reported by: jri Owned by: jri
Priority: Major Milestone: Release 4.8
Component: DeepaMehta Standard Distribution Version: 4.7
Keywords: Cc: dgf, Malte, JuergeN
Complexity: 5 Area: Data Model
Module: deepamehta-core

Description (last modified by jri) (diff)

Real world observation has revealed there are 2 different kinds of types:

  • Types that are general purpose in the sense whose instances are not assigned to a particular workspace (resp. "application"). You could say these types are cross-application. For these types a created instance would be assigned to the current workspace. That is the mode currently implemented as of 4.7 (and before).

An example is "Person". It seems perfectly natural that in a DM installation e.g. the 2 workspaces "Computer History" and "Money Job XY" exist and that both contain Person instances. That is while sharing the same type ("Person") its instances exist in 2 separate realms with individual access privileges.

  • Types that are application-specific in the sense that all instances belong to a particular workspace that is part of the application (e.g. "Wikidata" or "CROWD"). This is useful for the use case Collaborative authoring of public data in private views. For these types a created instance would not be assigned to the current workspace but to the workspace the type is assigned to.

The setup would be as follows: the application workspace is public. The application-specific types are assigned to it and all collaborators are members. DM will then assign created content to the application workspace (regardless of the workspace the user is in) and thus grants WRITE access to all collaborators.

This is a powerful feature as users still benefit from DMs private views while doing collaborative work.

To realize this 2 things must be done:

  1. ensure every type has a workspace assignment (see also #371).
  1. meta model extension: a topic type (as well as association) needs a flag that reflects wether the type is application-specific or not.

Change History

comment:1 Changed 5 years ago by jri

The realization approach with the flag (task 2. in the ticket description) might not be suitable in case an application regards a type that is part of the DM Standard Distro (or of a 3rd-party module) as application-specific. E.g. the CROWD application regards the Event standard type (as of DM 4.8) as application-specific. As a consequence the CROWD module must set the "application-specific" flag for Event. But DM then would assign all created Events to the DeepaMehta workspace and not to the CROWD workspace, which would be intended.

At the moment I see 4 possible approaches:

  • Every CROWD member must also be a DeepaMehta member. The Events could stay in the DeepaMehta workspace then.
  • The CROWD module reassigns the Event standard type (as well as Person and Institution) to the CROWD workspace. Created events would land in the CROWD workspace then. I don't like this approach as the CROWD module could rely on other modules which also might want to reassign the types. This could produce a conflict situation.
  • Melt the DeepaMehta and CROWD workspaces down into one workspace, that is, the CROWD module would rename the "DeepaMehta" workspace to "CROWD". I don't like this approach for 2 reasons:
    1. in the face of the related (and still to be realized) concept of a "Home" workspace (see #371) the CROWD types (Work, Translation, Event Series, Entrance Fee, ...) must get a "dm4" URI prefix then despite this prefix is reserved for the DM standard types. At the moment "DM standard type" means "part of the DM Standard Distro".
    2. the CROWD module could rely on other modules which also might want to rename the DeepaMehta workspace. This would produce a conflict situation.
  • Do not model the "application-specificness" (in the sense of the ticket description) of a type as a flag, but as an explicit type assignment. That is a type can have 2 independent workspace assignments, the standard assignment, and another one that reflects the application workspace. The latter one could be called Destination Workspace (as created instances are destinated there). E.g. the Event type would be assigned to DeepaMehta and its destination workspace would be CROWD.

None of these approaches feel natural to me. Too complicated.

The base problem is how to separate DM from CROWD, or in general: how to separate DM from the installed applications? I see a general conflict here: while the user wants a unified experience some kind of separation is required as the installed applications/modules must not conflict with each other.

We should further contemplate on this.

Last edited 5 years ago by jri (previous) (diff)

comment:2 Changed 5 years ago by jri

  • Description modified (diff)
Note: See TracTickets for help on using tickets.