How 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.
  • edited September 11, 2007
    On this quickly ...
    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?
    Google for "FRBR"; what you describe is essentially its work/expression/manifestation/item hierarchy.

    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.
  • "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.
    MTBradley--what would go into the "Function" field?
    Second, there is a real need for something similar to the "Person" and "Collections" types availabe in Scribe3.
    Ticket for these exists but they might have to wait till the new hierarchical item type model is implemented.
  • Something I often wondered about: how to represent a woodcut or a pen drawing printed in a book? Instead of using "Book Section" (which it often is not) I use "Artwork."

    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?
  • This will be available in the hierarchical item types system--you'd enter it as an Artwork "contained in" a Book.
  • MTBradley--what would go into the "Function" field?
    Some examples might be “Clothing”, “Container”, “Musical instrument”, and “Weapon”. The option to add multiple instances of such a field as you can with the “Author” field in the current set-up would helpful given that many artifacts are multifuncional. (Come to think of it, such an option would be nice for other fields, particularly “Series” and “Series Number” as a book is often a member of multiple series. AAA requires series information in the bibliographic entry and I’ve dealt with this by entering all the series and information in the same field, for example “University of Tennessee, Department of Anthropology, Report of Investigations 43 and Tennessee Valley Authority, Publications in Anthropology 41”.)

    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.
  • edited September 14, 2007
    To play devil's advocate, though, would one ever cite a shirt or a weapon? At what point do we draw the line and say this is beyond Zotero's (and related efforts') scope?

    Also, I don't think "function" is really right. You're just talking about classes of objects (aka a type).
  • edited September 15, 2007
    Looks like there is a need for an "Artifact" item type, not for citation, but for keeping track of physical objects (I guess this would be most useful for archaeologists and folklorists?). "Artwork" is meant mostly for visual culture items for citation purposes, hence the fields for Medium ("safety negative") and Size ("3 1/4 x 4 1/4 inches"), whereas "Artifact" would probably have "Type" (shirt) and "Medium" (wood). "Artifact" probably falls under the same category as a "Person/Biography" item type and partly "Archival Collection"--it's more for keeping track of research than for citation. But it seems from this discussions that it makes sense to include it in the future. In the meantime, one could just use the "extra" field to store additional data.

    Bruce--
    Just checking--do you plan to include non-print media in your ontology (films, audio recordings, tv/radio broadcasts)?
  • Bruce--
    Just checking--do you plan to include non-print media in your ontology (films, audio recordings, tv/radio broadcasts)?
    I really want to, but it's just tricky to figure out how best to do it, and we also want to avoid boiling oceans and get too far into the terrain of other ontologies.

    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.
  • Please see the type revision discussions at http://forums.zotero.org/discussion/15636 and https://github.com/ajlyon/zotero-bits/wiki/Zotero-types-whiteboard .

    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.
  • @ajlyon: the wiki page at github is awfully difficult to read and comment on. It's probably too late now, but it might have been easier to open up the issue tracker, and then create separate issues for each type, with itemized lists of new fields, open questions, etc.
  • @bdarcus: we can still switch to using an issue tracker (some proposals still need to be ironed out anyways). Dan, Simon, do you have an opinion on the matter? We could also move everything over to Zotero Trac, but it might be easier to stick to github.
  • I know I haven't been contributing much on this, anyway, but Zotero Trac seems like a really bad idea - it's so slow and unwieldy.
  • Yes, I wasn't suggesting using Trac. The github issue tracker is quite nice.
Sign In or Register to comment.