Upgrade StorageHow might the "Artwork" type be expanded?
I have a couple of suggestions for ways in which the "Artwork" type might be might be tweaked to make it easier to use for those who do museum-based research and whom have to deal with a lot of images (particularly maps).
First, I know that "Artwork" is probably intended as a catch-all type for any sort of thing that can be kept in a museum, but the name feels odd from the point of view of an anthropologist. Not all cultures have the concept 'art', and in those that do many of the pieces of material culture that end up being collected and curated are produced and utilized with an explicit understanding that they are not art. But apart from the semantics, the type has some shortcomings for "non-art" objects. "Medium" could be used like a "Material" field (keeping in mind that this is often difficult to label with a single term), but the type still lacks a "Function" field. I know that these can be dealt with by using tags, but as tag proliferation apparently needs to be avoided with Zotero I wonder if a new field is not a better strategy?
Second, there is a real need for something similar to the "Person" and "Collections" types availabe in Scribe3. An art historian can't do their work without collecting detailed information about particular collections and a folklorist has to do biographical work. My quibbles with the "Artwork" type can all be solved with workarounds in the current Zotero setup, but these two issues can not.
Thirdly, is there some way to use the hierarchical system that is in the works to make cartobibliography (as well as image management in general) more manageable? Consider that I may need to do all of the following: cite a map in its original form (published or manuscript), keep track of subsequent published reproductions of that original, as well as keep cataloging information on individual archival holdings of the original. I may also have paper and digital images of any and all of the above. Can I nest them so that the original MS or published map is on top of a hierarchy with stops along the way at archival holding, published copy, and Zerox/Scan? (I think this gets to a broader issue involving information management and images. How easy and intuitive does an application make it to manage information about a published/well-known image versus managing information about a particular reproduction you have of it? This is the sort of issue that one of my linguistics professors would refer to as a "token/type" problem.)
Apologies if I haven't gotten this all out in the most articulate fashion. I realize that the naming convention for the "Artwork" type as well as the number of and labels for its fields are more minor points. But I think my second point is a real one- an application intended as a complete research tool for the social sciences and humanities should have an option for building and maintaining collection and biography files. The third point might seem a little OCD, but as digital data accumulates through the years I predict it will become more pressing.
First, I know that "Artwork" is probably intended as a catch-all type for any sort of thing that can be kept in a museum, but the name feels odd from the point of view of an anthropologist. Not all cultures have the concept 'art', and in those that do many of the pieces of material culture that end up being collected and curated are produced and utilized with an explicit understanding that they are not art. But apart from the semantics, the type has some shortcomings for "non-art" objects. "Medium" could be used like a "Material" field (keeping in mind that this is often difficult to label with a single term), but the type still lacks a "Function" field. I know that these can be dealt with by using tags, but as tag proliferation apparently needs to be avoided with Zotero I wonder if a new field is not a better strategy?
Second, there is a real need for something similar to the "Person" and "Collections" types availabe in Scribe3. An art historian can't do their work without collecting detailed information about particular collections and a folklorist has to do biographical work. My quibbles with the "Artwork" type can all be solved with workarounds in the current Zotero setup, but these two issues can not.
Thirdly, is there some way to use the hierarchical system that is in the works to make cartobibliography (as well as image management in general) more manageable? Consider that I may need to do all of the following: cite a map in its original form (published or manuscript), keep track of subsequent published reproductions of that original, as well as keep cataloging information on individual archival holdings of the original. I may also have paper and digital images of any and all of the above. Can I nest them so that the original MS or published map is on top of a hierarchy with stops along the way at archival holding, published copy, and Zerox/Scan? (I think this gets to a broader issue involving information management and images. How easy and intuitive does an application make it to manage information about a published/well-known image versus managing information about a particular reproduction you have of it? This is the sort of issue that one of my linguistics professors would refer to as a "token/type" problem.)
Apologies if I haven't gotten this all out in the most articulate fashion. I realize that the naming convention for the "Artwork" type as well as the number of and labels for its fields are more minor points. But I think my second point is a real one- an application intended as a complete research tool for the social sciences and humanities should have an option for building and maintaining collection and biography files. The third point might seem a little OCD, but as digital data accumulates through the years I predict it will become more pressing.
I personally think the model is too complicated for these sorts of applications, since it gets really hairy to deal with common things like articles, which also don't really benefit from the added complexity. But certainly worth looking at, and there may be ways to bring in some of the ideas in a more relational Zotero model.
But it seems to me that there is no straightforward way to indicate that the work was published in a book -- although the book title seems to belong in "Repository." But where to note the page number(s) (pen drawings are often printed between two numbered pages)? Where the place of publication?
A “Type” field would also be useful. Example entries would ibclude “Shirt”, “Basket”, “Drum”, and “Bow”; as you can see the entry would be related to but not equivalent with “Function”. This field would not be unlike Artwork’s “Medium” field though I don’t think “Medium” would be an apt title for it.
Also, I don't think "function" is really right. You're just talking about classes of objects (aka a type).
Bruce--
Just checking--do you plan to include non-print media in your ontology (films, audio recordings, tv/radio broadcasts)?
The ontology is focused on documents, which I guess one could conceive broadly as a communication of ideas committed to some medium.
So I think it's easy to handle different kinds of recordings in that context, either by creating subclasses like AudioDocument and AVDocument, or by using properties to encode that information in a generic Document description.
Broadcasts are trickier, since I'm not sure we could consider them documents per se. Surely there are documents of them (mp3 podcasts, DVDs, streaming video, etc.), but that's not the same.
But we do need to figure this out. On a selfish point, I do cite broadcasts (say interviews), though often online transcripts of them.
It may be possible to make changes to the artwork type in Zotero 2.1, but the existing discussions don't provide clear indication of what should change, what fields are needed.