Restoring references from embedded metadata

[Frank Bennett]

I've added a couple of features to MLZ to facilitate collaboration, and I'm wondering whether there is interest in a pull request against one of the Zotero branches.

The features are:


(1) Project name tagging

The user can set a "Project name" in Document Preferences, which is applied as a special-purpose tag on references contained in the document, wherever they are located. Project tags have the following characteristics:

* They rise to the top in the Tag Selector (just below colored tags, if any)
* They have distinctive markings to distinguish them from ordinary tags
* They cannot be colorized or renamed
* They can be applied to items in read-only libraries
* They do not sync

This was my quick-and-dirty solution for "document collections", but now that it's in place, I think I prefer it to a virtual collection or library, since it leverages concepts already familiar to users.

Release announcement: http://citationstylist.org/2014/04/27/multilingual-zotero-tagging-cited-items/


(2) Out-of-document reference extraction

The user can set a group library to which they have write access as the target for extracting "surrogate" into their database. If a user receives a document "bound" to a library to which they do not have access, they are given guidance on how to proceed.

Release announcement: http://citationstylist.org/2014/05/03/multilingual-zotero-extracting-embedded-references/


If there is interest in adopting these features (or something like them) in mainstream Zotero, I can work up pull requests for them. I'm sure that the coding would need some work to bring it up to standard, but both features have worked out pretty nicely, and I think they would be well received by Zotero users.

Frank

[Dan Stillman]

Thanks for the offer of pull requests. I think I'd still prefer for this to be implemented as virtual collections in mainstream Zotero, which I think will fit more naturally into the interface. Doing it that way also obviates the need for the second feature (if I understand it), since you can just drag items from the virtual collection to a library to convert them into real items. That's exactly how feeds [1] will work, which should help create a pretty consistent user experience. (I haven't totally decided how to implement feeds — and specifically whether those will be stored as real items or virtual items — but it's possible this will be able to piggyback off of some of the same work.)

[1] https://www.zotero.org/blog/feeds-and-institutional-repositories-coming-to-zotero/

--
You received this message because you are subscribed to the Google Groups "zotero-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zotero-dev+...@googlegroups.com.
To post to this group, send email to zoter...@googlegroups.com.
Visit this group at http://groups.google.com/group/zotero-dev.
For more options, visit https://groups.google.com/d/optout.

[Frank Bennett]

On Sun, May 4, 2014 at 3:25 AM, Dan Stillman <dsti...@zotero.org> wrote:

Thanks for the offer of pull requests. I think I'd still prefer for this to be implemented as virtual collections in mainstream Zotero, which I think will fit more naturally into the interface. Doing it that way also obviates the need for the second feature (if I understand it), since you can just drag items from the virtual collection to a library to convert them into real items. That's exactly how feeds [1] will work, which should help create a pretty consistent user experience. (I haven't totally decided how to implement feeds — and specifically whether those will be stored as real items or virtual items — but it's possible this will be able to piggyback off of some of the same work.)

[1] https://www.zotero.org/blog/feeds-and-institutional-repositories-coming-to-zotero/

I can see the attraction of virtual document collections, as a more compact Zotero-side view of a project's items. I think there might still be a case for something like patch number (2), though. Thinking out loud ...

(A) In a collaboration, if one author cites from their private library, the second author would see those items in the virtual collection, populated with metadata pulled from the document. In the document, the "Open in ..." button would work on all items to expose the item in the virtual collection, in read-write state if the original item is accessible and editable to them, and otherwise in read-only state. So far, so good.

If one author wants to make a change to an item that is read-only to them, they can drag it into a library and do the edit there. Integration can link the URI of that item in the document as the preferred target. The document will contain the updated metadata, and (depending on how document-based virtual items are implemented) might show the new item content in the document's virtual collection. But if the first author dragged the item into a library to which the second author has no access, a refresh will reformat the citation with the original (now second-best) version of the metadata. The transparency of the UI could then become a source of confusion, as the two authors try to work out why the citations are rendering differently in their respective environments.

The problem is similar to a sync conflict, but in the context of the document, rather than the sync server. It could be handled in a similar way, but there would be three possible choices for the first author, not two: force the document reference back to their own version; adopt the second author's changes in their own private item; or create a new item with the second author's changes. One of those choices could be made to happen implicitly to avoid breaking up the flow of editing work, but there would still be occasional confusion over where the data is coming from.

Setting a shared library for read-only items in document preferences avoids the complication by single-sourcing document references before conflicts arise. So even with virtual document collections (which I agree would be nice than applying project name tags to items in their respective "real" libraries), providing an option to designate a shared library for inaccessible items might still make sense.

(B) In the implementation, I guess there would be a choice between making virtual collections persistent or ephemeral, and between making them document-centric (one collection per document) or project-centric (one collection spanning several separate but closely related project documents). There might be benefits in persistent, project-centric collections in a complex project, but after writing out a description of scenarios where it might be useful (and then deleting it), I'm inclined to think that simple is better. :)

To sum all that up, virtual document collections sound great, but I think they would work best if supplemented with an option to designate a shared library for inaccessible items.

(The current extension in MLZ serves our purposes for the present, and it's low-impact, so the changes can just be rolled back out when virtual document collections become available.)

Frank