-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhancement: Use Zotero items relations (owl:sameAs, dc:replaces, but not dc:relation) to update archiveLocation/extra #26
Comments
I don't yet understand how these relations would be used for this. |
The IDs mentioned in those relations ("dc:replaces" and "owl:sameAs", but not "dc:relation") should be written into the item in Extra:
(see #27) |
When should they be written there? And why? If Zotero administrates this already, why duplicate this information rather thanjust showing it? |
Whenever the plugin function that places IDs into "Extra EdTechHub.ItemAlsoKnownAs", those fields should be checked, and the IDs present be added to "Extra EdTechHub.ItemAlsoKnownAs". Yes, Zotero administrates it, but e.g. some of the information is removed (e.g. when moving). We want to preserve a full trail of previous IDs, and make that visible to the user. Does that explain? |
As I think I have provided the needed information, I'm removing the label. Feel free to re-add! |
But then I'd have to reconstruct what happened to the item somehow. There's no place to get both the ist and the soll for a save, except for merges. |
Hmmm. I'm not sure I follow. Are we talking cross purpose? :) The json shown above is part of the item record, stored in Zotero. I assume that those fields ("dc:replaces" and "owl:sameAs") can be inspected by our plugin. The proposal is this: When I use the edtechhub-plugin right-click menu item "Add persistent id -> archiveLocation" (old) or "Add id to Extra" (new), then the plugin inspects "dc:replaces" and "owl:sameAs" (but not "dc:relation"). If there are IDs that currently aren't in
then they should be added (see #27). I.e. whatever is in "dc:replaces" and "owl:sameAs" at that moment is added. Doesn't matter if that's changed in the past - we can only pick up whats there. |
So whenever an item changes, I should just write the values of "dc:replaces" and "owl:sameAs" into "alsoknownas"? |
It would be good to this
The item merge is destructive, but I cannot see other operations that would be. |
🤖 this is your friendly neighborhood build bot announcing test build 0.0.23.228 ("also on merge") Install in Zotero by downloading test build 0.0.23.228, opening the Zotero "Tools" menu, selecting "Add-ons", open the gear menu in the top right, and select "Install Add-on From File...". |
For me, this isn't working yet. Example
This item now has
Only
appears - this is correct, but I was also expecting
Am I misunderstanding? |
Also, when two items are merged (with just this plugin installed), no 'item history' is produced. With 0.0.23.226, this worked fine. Maybe the attempt to do the present process during the merge interferes with the history writing? |
🤖 this is your friendly neighborhood build bot announcing test build 0.0.23.230 ("merge can't access 'this'") Install in Zotero by downloading test build 0.0.23.230, opening the Zotero "Tools" menu, selecting "Add-ons", open the gear menu in the top right, and select "Install Add-on From File...". |
Thank you - this is working! Please release! |
Zotero items have these relations:
or (if several merges)
dc:relation is set manually, however, the others are automatic: Some through merging ("dc:replaces"), some through moving to a different library (owl:sameAs).
The text was updated successfully, but these errors were encountered: