Bruce said:
"I would absolutely hate to see any app displaying all my collections in a table view"

I understand this. However, as outlined above there are use cases for this, so I guess it depends on your needs whether you'd like to see a collection item as an individual item or not. IMHO it would make the inherent logic easier understandable for the user, since *all* items are treated equal and you could relate all items with each other using exactly the same way in the GUI. Also, editing would work in the same way for all item types which is beneficial. Why should I be allowed to edit some items in its own record entry mask, while other items can only be edited from within another item? This doesn't feel like a good UI concept to me. Also note that there are many possible ways to deal with the display of collections in the interface, e.g., the interface could hide collection items by default but display them within a special folder, "saved search", etc.

Speaking of "collections" vs "containers", I think we should really define what these two words mean for us. I have the impression that for some people these two are interchangable words for the same thing while for others it's not. So I'd appreciate any clarification. Personally, I like Bruce's simple definition of a "collection" being a set of multiple items. I.e. a collection is always a container for something else. OTOH, a container is not necessarily a collection. The prominent example would be an edited book which is still a stand-alone item and as such regarded as a document. Would other people agree with this thinking?

"As for collections being perhaps more about a relation, I'm not sure; perhaps."

I have no problems with "collection" being a hierarchical concept, in fact I like it and I agree that the concept of a collection helps with things like citation formatting. But in my above post, I wasn't necessarily implying that a collection would merely be a "relationship qualifier", I was just saying that collection item types should be treated similar to document item types and that there are multiple useful relationships (with "reproduced in" being only one of them). If one regards a collection as a group of item types that comprise a set of multiple document items, the relationship could still be described by the container logic (i.e. "is part of", "is contained within" or "is reproduced in"). So I don't see any problems here.

Matthias,

I also like the idea of building in a capacity for lots of different kinds of relationships, and many of the ones you mention make sense (though many of these would not matter for purposes of citations, there are other benefits).

That said, it's also worth keeping in mind that many of these "relationships" are simply variations on the basic relationship "is in," where the medium (microform, facsimile, review, etc.) would be evident from the data or the entry type. If I am citing a document from a microfilm collection, it's self-evident that this is a microfilm reproduction of the original document. The specific relationship type is indicated by the entry type (in this case the container entry type) and therefore it would be superfluous to designate that relationship via a special "relationship type." So by all means, let's include all the relationships that will be useful - but let's not create more types than are necessary or useful.

But perhaps it's worth stepping back and asking what we're trying to accomplish here. If we're interested in generating citations, then we don't need many relationship types - only those that are necessary for citation needs. If we're interested in creating a database that can quickly show us all the various incarnations of a particular source, then we could be talking about a lot more. Or we could do the first right now, because there's a more immediate need for citation management (without which you'll never get a big database filled with sources), while leaving open the possibility of creating a more open-ended relationship structure down the road.

Another thought on this: the microfilm reproduction is obviously a microfilm reproduction because the medium is included in the citation info. Perhaps this could be a model for most of the others, as well. For entry types where relationship status is not obvious, you could insert tags within the record identifying the medium as "exact reproduction" or whatever. This could be a lot simpler than creating lots of "relationship types" and would accomplish the same purpose. For example, as anyone who has worked with manuscript letters knows, there are sent copies, retained copies, draft copies, additional copies made by the recipient, etc. In other words, lots of potential "relationships" needing specific types. But by simply designating these characteristics within each record, you could obviate the need for specific relationship types - you could simply create a generic relationship, and let the attributes of the records indicate the precise nature of that relationship.

CloudofDust, I agree with you that many of my previously mentioned relations may not be needed for purposes of citations. I presented them simply to show that one hard-coded relation may pose a serious limitation and that a redesign of the data model (which is the core of the app) should try to be flexible enough so that the model can be expanded easily to address future needs.

CloudofDust is also right in that the types of the related items (plus any other field info) can account for many (if not all?) of these relations, though IMHO this pretty much brings us back to the current flat model with many item types. Current bibliographic apps do *exactly* this, they base the inherent hierarchic relations and the citation formatting on the item's type and draw logic from specific fields (such as medium, language, number of authors, editor present, etc).

It's correct that many of the above given relations are variations of the same relationship type and I wasn't really implying that Zotero should offer all of these, just that the system should be expandable.

To suggest something more concrete, I think that at least these basic relations would make sense for a bibliographic app:

is a copy of (e.g. exact copy, reprint, facsimile,..)
is reproduced in (e.g. microfilm, book, newspaper,..)
is a version of (e.g. revised edition, translation, illustrated/abridged version,..)
is a derivative work of (e.g. summary, screenplay, parody,..)
is a descriptive work of (e.g. review, criticism, commentary,..)
is presented at (e.g. conference,..)

CloudofDust said: "Perhaps it would be helpful to move past the abstract question of ideal levels of flexibility, or how a container is different from a collection, and talk instead about concrete design choices that will have to be made."

I understand this, however, you want to redesign a core element of your app (such as the data model) only *once*, so these discussions are important to get it right. IMHO the general discussion is really important since it's the basis for any concrete suggestions and user interface design. Nobody said this would be easy.

Sorry for disappearing for a few days (somehow, my RSS reader flaked and stopped indicating new posts to this thread)...

A few posts back, CloudOfDust pointed to an apparent contradiction between two statements of mine, one of which seemed to advocate for flexibility in relationship-determination while the other explained a need to hard-code certain of those relationships. While the two seem contradictory, I meant them on different levels; the former is about the conceptual (and general) data model for bibliographic information, the latter is about Zotero's particular implementation of it.

Again, my biggest concern right now is figuring out a core model and interface for Zotero that, while not infinitely flexible, is not incompatible with other implementations of a more flexible model. For example, while we might not implement dozens of possible qualifiers to a relationship (a la Matthias' more exhaustive list above), it's clear that we need a "valence" property associated with any relationship that could cover everything from "reproduced in" to "version of"...

That said, I think we've covered some good ground here; in the next few days I'll see if I can distill all the issues raised into a new spec, and we can discuss from there (in the hopes of getting something implementable much sooner than later)...

It appears to me that Zotero still focuses on the bandwagon of nicely looking and apparently cool web features.

Del.icio.us and Flickr are also “cool,” indeed. Tags are really “cool” as well. So is my iPod. And so are many of the features that come with the recent developments in internet applications, especially when it concerns digital scholarship.

Besides the added stability and increased speed of Zotero when it comes to large and serious bibliographies, it feels like the recent upgrade consists of yet a few other “cool” features.

Emblematic of this is the last post on the forum concerning “annotate and highlight archived pages,” which basically refers to the possibility of adding comments to saved websites.

Gee, that’s so great – especially given the fact that most serious scholarship takes such “archived pages” very, very seriously.

Zotero had (or still has?) the capacity to revolutionize the way we (i.e. scholars who deal with the archives on a daily basis) manage our data. The fascinating discussion on hierarchical relationships and parent-child-items was an example of that.

None of the Thompson products is able to handle such issues.

Neither Endnote nor Procite can deal seriously with cross-referencing (although Procite claims it can). None of them can define specific relationships between containers and that which they contain; neither of them knows how to deal with parent-items and child-items in a visually transparent manner; etc.

Zotero had (or still has?) so much prospects to address these fundamental issues with reference to bibliographic databases.

Thanks for the added stability. Thanks for the increased speed when it comes to large collections. But seriously, were we all waiting to be able to make some notes to some forsaken website?

In any case, I waited for the recent update but nothing much seems to have happened.

Yet I did start to import an annotated bibliographic database of 1550 items into Zotero. This goes to show my dislike of the Thompson products and my optimism with reference to Zotero.

But whatever the developers might claim, importing such a large database into Zotero does involve a good amount of manual labour, even with the supported export files.

I just wonder how it would be when in a future update we will be able to use parent and child items. Am I going to have to change them manually again?

S.

I agree with CloudofDust and also have to say that my previous write up was harsh and unfair perhaps. I imagine to have been inspired by the disappointment I felt when this thread seemed to have disappeared amongst the many other discussions, which seemed more frivolous to me. And in the end, Zotero is, of course, more than just a great research tool and, of course, people's interests widely differ.

Thanks for all the effort!

We are committed to implementing a new data model along these lines, but it's a major undertaking that will need to wait until we have ironed out the issues related to bringing synchronization functionality online. The Zotero project is led by historians and other humanists, and we are as eager as anyone to see Zotero support the kinds of container relationships that are critical to serious academic scholarship.

This may not be the right thread for this, but I'd like to make a request for a hack until parent child relationships are implemented. Is there a way to copy fields from one record into another? That might at least speed up data entry if one is trying to input 20 chapters of an edited volume.

The scraper would pick up the parent and then we would use this special cut and paste while entering the data for the children. The action need not imply any particular relationship between the two entries. The data structures would remain flat. It would simply make it easier to enter the data. It's inheritance by copy and paste, much as I would do if I had the bibtex entries open in emacs.

erazlogo,

Thanks for the tip on that. However, I don't think that does anything about the bibliography -- for which I would only want on entry. And really what the parenthetical should like is:

(Davidson [1967] 1984) or (Davidson 1967/1984)

And the list of citations should only have one entry.

Dean

Hi all,

Is this the thread with the most recent info on hierarchical relationships between items? If so, does anyone know what the status is of this feature?

I'm sorry if this has been already addressed, but isn't it just as easy as creating a gui that let's you subordinate/create one item as a child of another (initially populating itself with as much data from the parent as possible). Then you can cite the children to your heart's content and the bibliography would automatically be built with only the parent's info...?

-A