Ticket #924 (new Enhancement) — at Initial Version

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


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

2) meta model extension: a topic type (as well as association) needs a flag that reflects wether the type is application-specific or not.

Note: See TracTickets for help on using tickets.