search

edtechhub / zotero-edtechhub

https://github.com/edtechhub/zotero-edtechhub/projects/4
12 stars 3 forks source link

Is it possible to patch item moves from one library to another? [OBSOLETE] #57

Closed bjohas closed 4 years ago

bjohas commented 4 years ago

In the same way as we are preserving item IDs (in extra-also-know-as) during a merge, is it possible to preserve item KEYS (not IDs) during a move to another library?

In other words: is a move to another library patchable on the same way as the merge is patchable?

retorquere commented 4 years ago

I don't think Zotero actually does moves from one library to another. I think it only supports copy.

retorquere commented 4 years ago

But if owl:sameAs gets set, I could see after creation if it has any libraryIDs in there that are not its own.

bjohas commented 4 years ago

Yes - it only supports copy and yes, owl:sameAs. However, when you copy to the new library, owl:replaces is removed. So it would be good to catch the move, and retain the item keys stored in owl:replaces?

Really, what we are doing is 'repairing' the fact that Zotero items don't trace their item key histories very well. (See two recent emails on Zotero dev list.) Really, it would be much better if items traced their own history like this.

There are several options:

(A) Change Zotero, so that item key histories properly appear in "relations".

Or, in our plugin:

(B) If possible via monkey patch: When an item is moved, preserve owl:replaces.

(C) When you do a "save item id" (manually), then plugin looks

It's unclear to me whether this should only be done once (i.e., only one lookup). Otherwise you might ultimately get back to templates etc or see unexpected behaviours. Or maybe it's better to just go through all items, finding as many IDs as possible.

Let's see what people say on the mailing list, and whether (A) is feasible. This would be the best way forward. If (A) cannot be done, then we can explore (B) and (C).

Thank you as always!

retorquere commented 4 years ago

Yes - it only supports copy and yes, owl:sameAs. However, when you copy to the new library, owl:replaces is removed. So it would be good to catch the move, and retain the item keys stored in owl:replaces?

But that's the thing -- there isn't a move. Extensions get notified after a new item is created but get no info on how it was created -- import, user-creation and copy all look exactly the same to the extension.

(A) Change Zotero, so that item key histories properly appear in "relations".

I tried meddling with the relations data in the past and that led to my account becoming unsyncable until I deleted all data in it. Maybe that's different now, but I'd not risk it. Zotero has assumptions built in about URIs resolving to within the group.

Or, in our plugin:

(B) If possible via monkey patch: When an item is moved, preserve owl:replaces.

There is no such thing as a move. I might be able to catch the drop on the other library, but that will again require a monkey patch. I'd have to go spelunking in the Zotero source -- I don't mind, but it'll take a bit. In addition to all that, I'd strenuously recommend not storing this in the actual relations table in Zotero for the reasons described above.

(C) When you do a "save item id" (manually), then plugin looks

* At the item (as before, i.e., recording information from owl:sameAs and owl:replaces; i.e., the functionality that's in the two PRs you've just about completed); this gives us a set of groupID:itemKEY pairs.

Possible of course.

* But now, we use those groupID:itemKEY pairs to up those items in other group libraries (if the user has access) and in the trash, to pick up extra owl:sameAs and owl:replaces from those items.

That should also be possible.

It's unclear to me whether this should only be done once (i.e., only one lookup). Otherwise you might ultimately get back to templates etc or see unexpected behaviours. Or maybe it's better to just go through all items, finding as many IDs as possible.

I don't understand this part.

bjohas commented 4 years ago

Thanks for the comment - I get the bit about the 'move/copy' not existing, but just the create in the new library. If the 'create' is monkey patchable, then

  1. the extension 'watches' item creation
  2. if item created (with GROUPID_A:ITEMKEY_B), then inspect item.
  3. does item have an owl:sameAs tag (pointing to GROUPID_X:ITEMKEY_Y)? If yes, we know it was just taken from another library (with GROUPID_X)
  4. In that case, go to the old item (with GROUPID_X:ITEMKEY_Y), and copy OLDITEM[sameAs, replaces] to 'also known as' for NEWITEM (with GROUPID_A:ITEMKEY_B)
  5. Finally, add GROUPID_A:ITEMKEY_B to 'also known as' for OLDITEM.

List items 3/4/5 could also be triggered manually by the 'save item id' (as noted above). When you do a 'save item id', it does everything it currently does (i.e., inspect the item GROUPID:ITEMKEY, plus look at owl:sameAs and owl:replaces), but then adds 'one iteration into the history of the item', i.e.

  1. Does item have owl:sameAs or owl:replaces tag?
  2. In that case, in addition to the usual stuff, go to each item referenced in owl:sameAs or owl:replaces tag, and copy OLDITEMs[0,1,2,3....][sameAs, replaces] to NEWITEM.
  3. Copy GROUPID:ITEMKEY of NEWITEM to each of the OLDITEMs[0,1,2,3,...].

This comment: "It's unclear to me whether this should only be done once (i.e., only one lookup)" or multiple times. I meant:

But let's ignore that for now - I think one iteration is enough (and sensible).

retorquere commented 4 years ago

I first want to clear the other open issue before I dive into this.

bjohas commented 4 years ago

Yes please - this is not urgent!!

bjohas commented 4 years ago

I've reformulated this issue as two new issues, and this issue can be closed.