Ticket #924 (closed Enhancement: wontfix)
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:
- ensure every type has a workspace assignment (see also #371).
- meta model extension: a topic type (as well as association type) needs a flag that reflects wether the type is application-specific or not.
Change History
comment:3 Changed 9 years ago by JuergeN
OK, so each TopicType? could have a destination workspace. I think this is somehow independ from the namespace questions. In any case the destination workspace can be programmaticly derived from the application's URI prefix, but it does not have to be. I can imagine many other situations where I - as a TopicType? designer - would also want to configure the destination workspace in the webclient.
As a result, the DeepaMehta Types can reside in the DeepaMehta WS and the CROWD types could be either in their own or not. But all instances of both types could land in the destination WS. On the other hand, the downside would be, that I could not add any content to other workspaces anymore - let's say I wanted to create a person instance or an event in my private workspace. The user would not know which rule actually applies (selected WS vs. destination WS). This also feels kind of a no-go and really should not happen in the same UI then. This could mean, that the destination workspace is only application specific and only reflects actions taken by the application (e.g. a new webfrontend for CROWD to enter their data). Then all data created by the application goes into the destination workspace and all UI interaction with the webclient remains as is. But I totally agree that all this does not really sound like a clear design yet.
The original starting point of this discussion was to think about the workspace as a desk or personal working environment, that should be mostly exclusive to the user, aiming to provider her with a stable work situtation. On the other hand the results of that work should be assigned to a collaborative workspace with her co-workers. As the views (TopicMaps?) and the data (instances) are both stored in the same workspace this is not possible because the same ACLs apply for both, the views and the data. To add some more complexity to this, the views (maps) are often part of the content and result of the work themselves. So it is not so trivial to devide the content in terms of views (maps) and data (instances of TopicTypes?). Tbc ...
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:
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.