Ticket #924 (closed Enhancement: wontfix)

Opened 8 years ago

Last modified 8 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 type) needs a flag that reflects wether the type is application-specific or not.

Change History

comment:1 Changed 8 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 8 years ago by jri (previous) (diff)

comment:2 Changed 8 years ago by jri

  • Description modified (diff)

comment:3 Changed 8 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 ...

comment:4 Changed 8 years ago by jri

  • Description modified (diff)

comment:5 Changed 8 years ago by jri

Thank you JuergeN for valuable feedback!
That's good you returned back to the original problem.
Thank you also for the fruitful phone discussion!
I think we've found a good design now :-)
This is now described in #927.

comment:6 Changed 8 years ago by jri

  • Status changed from new to closed
  • Resolution set to wontfix

Superseded by #927

Note: See TracTickets for help on using tickets.