items, attachments, copies

bdarcus

I recently suggested some changes in the organization of data in the Zotero UI (and probably the data layer). I'd like to expand on this.

Issues:

1. the distinction between the "url" field and "link" attachments is way too vague; I find it impossible to logically explain to my students


2. the new UI changes make accessing "link" attachments a PITA; I count three mouse-clicks (disclose attachments, access attachments, click link), when it should be one.


3. in general, the distinction I keep hearing between "user data" and "canonical data" is both too rough, and I think mischaracterizes the issues.


4. the related distinction between "info" and "attachments" is also too vague

My suggestion is a more useful distinction is among:

1. item data (titles, dates, etc.)


2. user data (tags, notes, access and update datetimes, bibtex-key like labels, etc.)


3. copies (what are now called "attachments")

Aside, FRBR is useful here, though the language is a bit different (frbr:Item = my "copy", my "item" = frbr:Manifestation or frbr:Expression)

The UI should clearly reflect these different types of data. I would go so far as to say that the info pane ought to be split into separate "info" and "user data" panes (or something similar).

Less directly related, but going back to the "canonical" vs. "user" distinction, you then forget about that as the primary distinction. You instead say that libraries have items with identities (denoted with a URI). The notion of "canonical", then, is not about the user data per se, but about trusted sources, where "user data" is understood merely as the most trusted source.

alexuw

Not sure I have a lot to add but I agree that the distinction between canonical-vs-user data is misleading, and item-vs-user better.

Another distinction here is between data model and UI. The data model needs to support a variety of tasks - producing citations, note-taking and tagging, querying, etc. The UI offers a representation of data, one that should correspond to a user conceptual model. Of course everybody's different, so UI design always entails tradeoffs. The most obvious being making it work reasonably well for both beginners and power users.

Bruce's suggestions derive from classroom experience. I think this is one of the most important inputs here. The process should be one of discovery as well as design.

For anyone interested in this, take a look at FRBR (Functional Requirements for Bibliographic Records). I wasn't aware of this - it addresses directly some questions I keep thinking about in relation to zotero data. Actually for me it raises a more fundamental question of data vs. the thing modeled, but that's probably OT for this thread.