Upgrade StorageAdd a document type
Hello, I'm a PhD student and I need to cite some scientific posters in an article. Would it be possible to add this type of document in the list ? I bet this could be useful for many people.
Thank you for your answer,
Olivier Godinot
Thank you for your answer,
Olivier Godinot
There is probably already an item type that could work.
Edit: Letter sequencing error
My guess is it's effectively the same as a conference paper, except it might need a genre note like "conference poster."
Agus
Authors
Title
généric name of conference
number of the conference
title of conference
date of conference
place of conference
But as alobo said, it would be nice to have a different type to make the difference.
Edit: Just to be clear, here's what ajlyon said in this topic:
For the user, knowing that a given item is a poster
and not a conference paper is important, as they do not
provide the same information and, in particular, not the
same way of communication.
Therefore, "poster" and "conference paper" should share all the fields except the most important one: the Item type.
The tag solution is not optimal.
The CSL issue is certainly important, but perhaps could be circumvented by linking both item types to the same CSL type?
I think that every user of Zotero is going to tell you that he/she prefers having a separate item type for posters. In terms of communication, they are actually almost as different as a paper and a video recording.
Anyway, thanks for Zotero! This is just a minor issue compared to the
great number of advantages.
Any answer from the Zotero staff would be highly appreciated!
For that reason item types are added in a very conservative manner with considerations as outlined above.
If one kept a bibliography only for one's self then a tag might be sufficient. But since we share these with colleagues, use them for citing others work in academic papers and put them on our CV the distinction is critical.
While I am sympathetic to the difficulty in accommodating many different kinds of sources I think this is a specious remark. I think you simply don't understand that the difference between a poster and a conference paper is like the difference between a conference paper and a journal article. It would be like categorizing an image as a video. Kind of the same, but not really.
So please, I hope you'll heed the requests from the many folks above and add poster to the item type list.
Thanks
I would suggest (and do myself) using "Presentation" for posters instead of conference papers. That also applies to papers given at a conference that are not published in formal proceedings. You can add "Poster" into the "Type" field, which will make the distinction clear for everyone you share that information with and will also appear in citations in most styles.
A DVD is a "Film" (or a "Video Recording"). In Spanish, "Película" (or "Grabación de vídeo")
There's no "Coordinador" (coordinator) in Zotero but check the different roles: in Zotero, if you click the triangle to the left of the director ("Directori") field you will be able to change it to "Contribuidor", "Guionista" or "Productor".
DVD supports something that could certainly be a film, but also can be a lot of documents with or without any film. And obviously would be different than a document paper supported.
When referencing a book writed by some authors, "Coordinador" is related to the type of author, like editor, (which by the way has been changed at the indautor agency).
I'm still not sure what a coordinador does. Remember we come from all different types of countries and academic traditions and we won't just know what's common in your country. In English and German, "coordinator" doesn't exist in academic publishing, there is just "editor" (or "Herausgeber"). In French, there is a distinction between a directeur, who is the person in charge of assembling an edited volume and an editeur, who publishes an edited version, say of a classic work.
If the former is referred to as "coordinador" in Spanish we can change that, but we'd need to be sure that that's true across the Spanish speaking world and not just in one country or set of countries. If this is true, say, only for Mexico, or only for Latin America, we'll need separate locale files, which is also possible, but requires more work.
The Zotero "Entry Type" is more explaining the set of data features it has.
This is not exactly matching the "real" type of object, that is cited. The use of icons and names are misleading on this!
For me often a type "Quote" (Zitat) seems missing, where I ca just cite a single saying without a context, but just mentioning Author and source.
I misuse "Instant Message" currently and use tags to make it a "Quote" for my personal use. But from a more general point of view I can strongly discourage this kind of tweaking.
Therefore I suggest:
* Keep "Entry Type" as it is for identifying the data-type
* Check if there is a general approach in the rdf or bibliographic standards for that!
* Decide if Zotereo can add a general "Descriptive Type" with a major list and a secondary customizable list of types. This is different from using free tags!
* Warn in the UI on use of secondary custom descriptive types initially, that those types maybe just exist in your personal cosmos and language
* Make clear that they are not supported in general and not result automatically in general value.
Implementation
* Make subclassing of types possible with addable custom fields that can be accessible via a container field if not supported by na application.
Conclusion
Yes, we can use Notes for that, but one additional structured field for the "physical type" would help a lot.
Armin
I am still proposing a "general field" "(sub)Type" to identify subclasses of an entry type in general not for "some" types.
So the difference of "Entry Type" in sense of datastructure and "Type" in the sense of the cited object still makes sense.
Not more than 25% of the entry types have a "type" field (or similar field from the entry type point of view). That is in spite of your expectation. I am not talking about the entry type that has no user changeable value list.
In the UI these fields are not placed at the same position next to the "entry type" at the top but somewhere. So it does not fulfill the requested feature at all.
Another point is that subtype icons are important too to reflect the (sub) type as well.
A challenging point is the "somewhat" naive understanding of people working on generalisations but related to their specific viewpoint they are missing others. This is often found in the ASCII culture that lacks the aspect of completely different concepts of language and understanding in other countries or areas (except the ovious ones). Zotero is an application with i18n support (i18n means internationalisation). That feature focuses not only solutions for languages but also regional differences. For a professional tool that scientists can rely on this is a must.
Especially the different citing styles (a main feature of Zotero) make clear why respect for different structures makes absolutely sense.
Limiting the differentiation to the subtype and icon (and translation) sharing common fields, will be enough to avoid bloating types.
There should be a differnce between "official" approved types, that belong to standards and not stzardardised types.
In Germany we have a long tradition with standards. But believe me: Before you get a standard you have use cases! Standards that were born theoretically are usually for the trashcan.
Since the solution is quite simple, we should not hesitate to offer a more general solution. It is not a good idea to leave records unspecific and misused. As OpenSource activist I am delivering solutions myself where I have the skills for it. Zotero is not my main sector, but I like the tool and it gives me very much value. So If someone points me to the right way to implement a beta feature, I would like to help out.
https://github.com/zotero/zotero/blob/master/resource/schema/userdata.sql#L359
We should not reinvent the wheel. I could not expect that the cool creators of Zotero are not thinking about a solution for this feature. As always it needs time for proper rethinking and implementation. One thing is the data, and one thing is the UI / UX representation.
Take care!
Cheers Armin
See:
Feature Requests: custom item type
https://forums.zotero.org/discussion/16137
[Sticky] Changes to fields and item types for Zotero 4. https://forums.zotero.org/discussion/15636/
Is there already a resource available?
http://aurimasv.github.io/z2csl/typeMap.xml
is the full type map which hasn't been changed for a long time.
Generally speaking:
1. Custom item types might(!) happen in the relatively distant future, but not any time soon
2. I'm rather confident we'll not add a sub-type category to Zotero item types - while I can't speak for Zotero developers (though my guess is they wouldn't take it either), I _am_ part of the Citation Style Language development team and that will never fly
3. We're happy to take specific suggestions for field or item type additions, backed up by evidence from style guides or author instructions. Post in the sticky field/item types thread.
(as a heads up - I hope this information is helpful, but I won't have the time or energy to discuss it with the exception of specific suggestions as per 3.)
I agree with the original poster, custom types would be very useful, for example the builtin type for The National Archives of the UK doesn't match their recommended citation style http://www.nationalarchives.gov.uk/help-with-your-research/citing-documents-national-archives/
I need to cite Parliamentary papers and from other non-standard sources, where there is no decent fit in Zotero, including for example:
Title:
Parliament Session:
Paper Series:
Paper Number:
Volume Page:
Volume:
Collection:
CH Microfiche Number:
Descriptive Title:
Page:
Having to enter citations such as this manually is frustrating when an otherwise brilliant application like Zotero exists.
Kind regards,
Julian
From my current viewpoint, instead of having Custom Types, it would be better to have a subclassing function that uses something similar to the extras field to extend the schema of the closest existing type and stay "migration resistant" with extended data in a container field (like with vcard files).
And yes, mainting an api for that may end as a nightmare....
-- Armin
Dive into the code, strip the fields and create the matrix as GDocs. This is how OpenSource works. Do it yourself! Take your chance to become contributor (if not already).
(or just create one of a type (put the UI fieldname in the content) and export. Then filter.)
-- CU