Should we really need to have type with different structure?

edited August 17, 2019
I believe we arriving to the end of the "old school citation" and we need a different approach where "type" is just one metadata like the others fields.

In my opinion, every document should have access to all the field. For example, a "report" should have an ISBN field, ISSN field and DOI.

For example, the journal become very blurry with preprint and repository services (SSRN, arxiv, …) . Those service provides sometimes DOI but are not peer-reviewed. Even some publication does not peer review. What I want is a radio-button "peer-reviewed" (yes, no, unknown).

Also type is very mixed with "medium". I have a hard time for example to add metadata for presentation or conferences that are actually video (YouTube). I don't need a producer for that.

In my opinion, it can be simpler and more powerful to have one structure to rule them all.
  • edited August 17, 2019
    1. Almost all styles treat different types differently, with different formatting. Even if two different types have publication years, for example, they might go in different places. Or a simpler example is that for books the title would be italicized, but not for journal articles. So until/unless all citation styles change to have only one "type" (that's not necessarily a bad idea, but it's not true now), Zotero must recognize different types to produce the correct bibliographies for styles. (That doesn't mean that the menu in Zotero needs to necessarily look different for different types, but you'd still need to select a type for each item.)

    2. Having additional fields available (like DOI) is planned for a future release. For now, you can manually add any of them in the "Extra" field as needed, for any item of any type. For example, type: DOI: 10.xxxx

    3. I personally like having different types so I can glance through my thousands of entries and know when I'm clicking on a journal article, book chapter, etc. Similarly, for many non-expert users, having the recommended fields associated with a particular item type seems useful. For example, having "publisher" for book but not for journal article is useful in that sense. There could be unusual times when you'd want to add a publisher for a journal article (maybe a very obscure or generically named journal), but (1) most citation styles will ignore it anyway, and (2) I'd say it's better for most users to have it somewhat clear what fields are expected for a certain type, rather than either missing some important information or feeling obligated to add in every last bit of information for every item even when you really don't need it.

    4. It sounds to me like you might need to think again about how types work in Zotero. There's a bit of a learning curve to some of them, but in general they're useful and cover almost all situations. Personally I thought that "Conference paper" was the right type to use for a "paper" (presentation) presented at a conference. But it turns out that should instead be entered under the type "Presentation", while a "Conference paper" is for a published paper in conference proceedings. Your example of a video of a presentation is actually one I'd recommend as a Presentation type, with a link to the video on Youtube: it is not actually a video conceptually, but you are just using that recording of it to cite it. (If it was a narrated video with added introduction, or something like that, the situation would be different.) As for medium, it's important to not mix that up with type, because an ebook is still a book, just in a different format (sometimes annoyingly without pages), but the same content.

    I agree with you that for unusual items that borders can blur a bit, but for now you can use Extra to add that information (check that the citation styles you're using actually support it though-- DOI is generally supported for all item types, for example, but maybe not publisher, and of course ISBN is rarely printed in any citations anyway), and there are plans to make the fields more flexible for different item types in the future.

    It seems to me that there's also a design question for Zotero: is it primarily a citation-generating tool, or is it primarily an information-organizing tool? (Or maybe both.) Some of the points you brought up fit more with the second use (adding ISBNs even if they're never cited, or adding whether it's peer-reviewed or not, again never actually citing that information in a bibliography). The ideas are reasonable, and others have also mentioned a desire to use Zotero to organize more than to produce bibliographies, but that's a different (or at least additional) philosophical direction, so something that the designers would have to think about (not me). Personally I like Zotero being optimized for generating bibliographies, but I do of course also use it to organize, so having some additional features like that, as long as they didn't get in the way of the primary purpose (in my mind) would be fine.
  • I think @gagarine is arguing that all fields be made available on all item types, not that the item type value itself be discarded.
  • So yes, there'll definitely be more fields for more items. I'm concerned that all fields for all items, though, may break a very, very large number of citation styles and create, frankly, infeasible amounts of work for mitigation, so I'd tread lightly on this (unless, of course, you're volunteering 2000-3000 hours of labor ;)
  • There are some fields (e.g. conference name, university, software developer) which are only meaningful for one or a few types. There is no advantages here to make _all_ fields available to all types; on contrary, I expect that this makes it much harder for the user to see which fields are expected for a given type and if an entry is completely entered or some important information might be missing. Instead I think there are _some_ fields (e.g. DOI, title, date, language) which should be available for all types.
  • edited August 19, 2019
    @fbennett yes exactly.

    @zuphilip I needed "conference name" for video recording

    For the interface you can display only some fields by default, but let edit all of them if needed:
    -> "basic fields" that are available to all item type.
    -> "specific fields" that are shown when you select a specific item type
    -> "show all field" button, that let you see all fields

    @adamsmith I see, this can definitely be problematic. I taught citation style would not break but simply don't show the extra field. So I guess we have wait 20 years or more has I'm pretty sure journal will take ages to update their style.
  • edited August 19, 2019
    As I said, you should be using Presentation as the type for that video, not Video recording. In this case, the video is like a photocopy of a journal article, in which case you would still cite as a journal article, not as a "photocopy".
  • @djross3 your point 4 is exactly the reason of my proposition. But I guess if at least we can have ISBN, ISSN, DOI and also place, institution and author it will already help a lot.
  • Yes, I think there are plans to make those fields available for more item types. (There are various discussions here. I think I remember one about how Swedish PhD dissertations are usually given ISBNs, for example.)

    I don't know that making the distinction between item types less obvious would be that helpful, though, and it might be more confusing. Renaming a few item types could help ("Conference paper" > "Proceedings paper" would make sense to me for example), but I think many users do actually rely on the hint of which fields are available when they try out different item types, and just go with what seems like it works. So giving more options could help in some ways and hurt in others.
  • With a bit of step back, I realize with this tread that peoples prioritize what "output the right result". On my side, I focus on data integrity and therefor the right meta-data, and the document type is one of them. If the output is wrong or if I can't add the meta-data because the field is not available it's a major bug.

    I used the database to run some experiments in the past. For example scrapping all blog post for a particular collection to check the content and do some automatic text analysis. I can not do that if the structure is not 100% right. Using "extra" is not an option neither as it will add a lot of complexity in programming such script.

    The current state is not future prof and the "extra field" is an hack that is going to be hard to migrate to a new structure.
  • Migrating content from entries in "Extra" to newly available Zotero fields will not be exceptionally difficult, since the mappings of Zotero fields to CSL variables are known, and the syntax of the entries is well defined. I believe that Zotero intend to automate migration as part of any upgrade that introduces new fields.
Sign In or Register to comment.