dm4-wikidata: as of 4.5 items with globally unique keys can end up in user space

[Malte]

In the current dm4-wikidata implementation the globally unique URIs of wikidata items (their URLs, e.g. "​http://www.wikidata.org/entity/Q42") are set as the topics URI. As these URIs are keys in DM4 they must be unique and thus every wikidata item can exist only once in each DeepaMehta 4 installation.

As of the collaborative version of DM (4.5+) this becomes an issue if such a wikidata item topic lands in a "users space", specifically, when the item lands in the "Private Workspace" of e.g. "Hans Theft".

The wikidata item in question, then, can not be READ by any other user of the same dm4 installation. It exists but every request involving this item (e.g. a search result bucket could not re-use the wikidata item topic) fails as an "Unauthorized" exception is thrown (to the plugin developer but most probably to the end user, too) while assembling the search result.

From a plugin developers perspective this means, that every re-use of any topic (dms.getTopic()) nedds to catch the "Unauthorized" case and implement a solution for the cases: 1) Topic exists already but is not readable for you and 2) Topic does not exists.

Now there are a couple of ways to deal with that but i would really like to hear others opinion on this case. I think, even in a multi-user installation one wants (and should be able) to work (read) with that wikidata item topic regardless of what other users do in this system.

Here are some ways i just came up with:
1 allow some sort of identifiable copy, something like an occurence of a wikidata item with a given URI (while an item can have many occurrences in one installation (will make things very complicated)
2 ask the other use to share this wikidata item with others again :)
3 prevent every user to assign a wikidata item topic to a workspace where it becomes unreadable for any other authenticated user (if possible)
4 overthink the complete data import scenario / use case (do not create topics for wikidata items in DM 4) but find another way make this data accessible, navigatable, associatable in DM 4

At the moment, i will probably go for 3) though this will certainly have curious side-effects for end-users of the plugin trying to re-assign/move a wikidata topic into their "Private Workspace."

Now, what do you think? Can you imagine other scenarios were we might run into a similar issue and how should we proceed there?

[jri]

Replying to Malte:

Now, what do you think?

From my point of view the most simple and natural approach is: when an item (topic/association) is meant to be shared it must not be assigned to a private workspace in the first place. That means your application (not the user) must control the workspace assignments of the items in question.

Can you imagine other scenarios were we might run into a similar issue and how should we proceed there?

Yes, I had a similar case with the shared file repos and collaborative browsing feature as of DM 4.7 (#815): when a user reveals a sub file/directory from a parent Folder topic the Files plugin creates the corresponding sub File/Folder? topic lazily. In this situation the topic must not be assigned to the current workspace (the standard behavior) -- which could be a private workspace -- but to the workspace the parent Folder belongs to. The Files plugin does so by suppressing the standard assignment and performing a custom assignment instead.

[Malte]

OK! Thanks for sharing your thoughts on this. This is the way i plan to go.

Questions regarding implementation:

• Which hook do i have to implement in my plugin to correct a user who is using the "Assign to workspace" command? The workspace plugin seems to not fire a dedicated event on this occasion. So it looks like, currently, when users use the dm4-webclient i am unable to make sure that my topics goes into a "Private workspace". A "postUpdateFacet" or a "postUpdateProperty" also does not yet exists (both seem to be involved in a workspace assignment via REST).
• Looking at the source leads me to the next implementation question: Can i somehow make sure that the workspace assignment done in my plugin (using "postUpdateTopic|Association") is triggered after the "postUdateTopic|Association" listener of the WorkspacesPlugin?? If so, how?

Thanks for your support!

[Malte]

That means your application (not the user) must control the workspace assignments of the items in question.

So, how would this be even possible right now (with the methods at hand of the plugi developer) esp. in regards of the "Assign to workspace" command? I still have problems to imagine how to achieve this.

[jri]

Replying to Malte:

Questions regarding implementation:

• Which hook do i have to implement in my plugin to correct a user who is using the "Assign to workspace" command? The workspace plugin seems to not fire a dedicated event on this occasion. So it looks like, currently, when users use the dm4-webclient i am unable to make sure that my topics goes into a "Private workspace". A "postUpdateFacet" or a "postUpdateProperty" also does not yet exists (both seem to be involved in a workspace assignment via REST).

Yes indeed, no such events (postAssignWorkspace, postUpdateFacet, postUpdateProperty) exist.

• Looking at the source leads me to the next implementation question: Can i somehow make sure that the workspace assignment done in my plugin (using "postUpdateTopic|Association") is triggered after the "postUdateTopic|Association" listener of the WorkspacesPlugin?? If so, how?

No, the order in which the listeners are called is undetermined. You have no guarantee that the listener L of plugin P1 called before/after the listener L of plugin P2. See #168.

Let me think about it ...

[jri]

Replying to Malte:

So, how would this be even possible right now (with the methods at hand of the plugi developer) esp. in regards of the "Assign to workspace" command? I still have problems to imagine how to achieve this.

The current approach to interfere with the workspace assignment done by the Workspaces module is the runWithoutWorkspaceAssignment() mechanism introduced in DM 4.7. That is your plugin actively suppresses the standard workspace assignment for a dedicated code block, and then cares about the assignments themselves. See ticket:752#comment:4 and following.

This however requires the code block in question to be under your plugin's control. To do so your plugin could define a dedicated resource method (REST API) to create the topics/assocs in question.

Would this work for you?

I'm aware this would not work if you want to interfere e.g. with the Webclient's "Create Topic" or "Assign to workspace" commands.

In that case I need to extend the Workspaces module with something like a "Assignment Customizer" mechanism. I could do so for the upcoming DM 4.7.1 release (but it would postpone its release date).