Representing citation trees in Zotero

Hello,

are there any efforts underway to represent citation trees in Zotero? We're currently storing citation trees by adding Zotero links to a 'special' note (which has the tag '_cites'), but it's not a very neat arrangement.

From my perspective, the best solution would be to build this into Zotero :) I'd be interested to know if there's thinking about that.

Otherwise, are other's interested in an add-on style solution? I could see two options:

(1) Add the data to 'extra' or 'callNumber' or similar. Then build a plugin that hides this extra data from the extra/callNumber/... field within the zotero desktop ui. The downside of this might be that this would be unwieldy in the the web ui; also, I'm not sure how much data a zotero field can hold (I know that notes are limited in size). Larger reports can have 100s of citations.

(2) Add the data to an item attachment (e.g., zotero-meta.json). One would then need a plugin that can display data from this file in the side panel (or in some other way), and create this file from a template as needed. {"cites": ["key", "key", "key", ...]}. (Alternatively, one could store the data in a single metadata.json file, but I imagine conflicts might arise more often.)

In both cases, the plugin would offer a relate-style function to see cited items.

Such mechanisms could also allow storing of additional metadata. Obviously, searching of that additional metadata would be limited to text searches of that field or attachment.

However, unlike storing additional independent metadat,a the citation trees have one central issue: The storage mechanisms for the citation tree needs to be aware of deletions and merges: When a zotero key disappears (or is rolled into dc:replaces through a merge), those keys stored in the citation tree and would need to be updated. I don't know whether Zotero would provide a solid 'hook' for this, or whether one would have to rely on monkey patching?

The current related items in zotero is bidirectional (and, from memory, stored in both items), so one can always find items affected by merges easily. So, perhaps one would need to make the citation tree storage bidirectional as well? {"cites": ["key", "key", "key", ...], "citedby": ["key", "key", "key", ...]} - this introduces redundancy, but would speed up operations in case of merge/delete.

Any views?
Sign In or Register to comment.