[New Feature] Custom Item Type
Hello,
I often have some entry for which I would like to have a non-existing specific type, e.g. tweets. I am a bit puzzled by the fact that I cannot, apparently, create custom types. I feel that such an option would be very useful to both the users (more flexibility) as well as the developers (because the users community could handle the development of new types).
Defining a custom item type would imply:
- Defining the name and icon (with, ideally, the possibility to use custom icons),
- Defining the type name for BibTeX (@…),
- Defining the fields: in addition to the many fields already available, it would be nice to be able to define custom fields (name in Zotero's UI, name in BibTeX, is it a string or a date or a name (like authors)…?).
Ultimately, it would also be great to be able to refine the way the data is collected when the reference is added from a web browser, i.e. define (for example) a list of domains from which the type apply (or a regexp test on the URL) as well as how fields are read.
Although a UI for creating new types would be neat, this is absolutely not necessary: defining new item types from some code would be sufficient for the feature to bring many benefits.
Note that this is more than just a user feature. Again, relying on the community to create and share custom types could allow more people to be involved in this task. Sure, everybody can technically contribute to the code through GitHub, but a) the barrier of entry would be significantly lower if one does not have to find their way through the whole project but just has to learn how to create one custom type, and b) highly specific types or flimsy-but-sufficient implementations should not be in the standard, shared software anyway.
Regards.
I often have some entry for which I would like to have a non-existing specific type, e.g. tweets. I am a bit puzzled by the fact that I cannot, apparently, create custom types. I feel that such an option would be very useful to both the users (more flexibility) as well as the developers (because the users community could handle the development of new types).
Defining a custom item type would imply:
- Defining the name and icon (with, ideally, the possibility to use custom icons),
- Defining the type name for BibTeX (@…),
- Defining the fields: in addition to the many fields already available, it would be nice to be able to define custom fields (name in Zotero's UI, name in BibTeX, is it a string or a date or a name (like authors)…?).
Ultimately, it would also be great to be able to refine the way the data is collected when the reference is added from a web browser, i.e. define (for example) a list of domains from which the type apply (or a regexp test on the URL) as well as how fields are read.
Although a UI for creating new types would be neat, this is absolutely not necessary: defining new item types from some code would be sufficient for the feature to bring many benefits.
Note that this is more than just a user feature. Again, relying on the community to create and share custom types could allow more people to be involved in this task. Sure, everybody can technically contribute to the code through GitHub, but a) the barrier of entry would be significantly lower if one does not have to find their way through the whole project but just has to learn how to create one custom type, and b) highly specific types or flimsy-but-sufficient implementations should not be in the standard, shared software anyway.
Regards.
It is possible that this is one reason that the APA 7th has so many examples for Social Media citations: https://apastyle.apa.org/style-grammar-guidelines/references/examples#online-media
Using the alias method, allows for a UI which matches the mental paradigms which user have, but also does not require support for new types according everyone's mental schema.
I believe that the alias method was used by papers 2 and papers 3 to give users access to a large variety of "item types" and still make them all citeable.
Item type: [Custom]
Format citation as: [Journal Paper] (Drop down, including the usual types.)
Custom item type: Tweet (Free text, i.e. can be entered at authors discretion)
Title: (Free text)
Author(s): ...
...
Followed by all available fields
...
Extra: (free text)
Custom field 1:
Custom field 2:
Custom field 3:
Custom field 4:
Custom field 5:
Date added:
Date modified:
There have always been questions how Generic fields would tie into the CSL. Here, the Custom fields are just ignored by the usual CSL styles. However, I could write my own, that would use those.
I'm not sure that custom fields are the right way to go either. I like them. I use them in EndNote, but is it the best way forward for Zotero? One way around the custom field issue for Zotero would be to allow CSL processing to access the Notes in Zotero. Notes could contain what is essentially a key's value (thinking in terms of key: value pairs): '__annotation', or '__isCiteBy', or '__cites' these values could then be acted-upon in some manner in the style sheet. It may be cumbersome in terms of the current UI, but in someways it lowers the amount of architecture changes needed to support customized data values.
to specify the style of citation for the custom item type on top of the chosen style help with the technical difficulty? No idea about this but would really like to see this implemented somehow.
type: EPRI
in the Extra field, the citation processor will treat the item as of type EPRI and it will apply rules from a CSL-style defined for that item type.The downside to this approach, and the reason why it isn’t promoted widely, is that it isn’t valid CSL (Zotero might warn you about it when you install a style containing invalid fields or types) and as such can’t be distributed via the style repository.
Other than that they're quite a good solution.
The fields I have in mind wouldn't need to be included in (custom) citations, but would rather just be available for filtering and record-reviewing purposes w/in Zotero's GUI.
In terms of UI, having the keys and paired values w/in the Info tab would be better than having it implemented in Notes, but I understand that might cause too much under-the-hood data design/maintenance/integrity/CSL-conformity challenges.
Tags could work for me. However, I'd tend to implement de facto key values as pre-pended strings before the value components of the tags, which is somewhat more cumbersome and (if heavily abbreviated) opaque. The "Extra" field can be used for this purpose as well, but has the disadvantage (field-internally) of being unstructured "free" text, and of not allowing for selection from (autocomplete-prompted) pre-populated lists to facilitate input speed and data consistency.
I regularly add policies to my bibliography and thus far I select "statue" for it. @hughp3 's suggestion would be really fitting.
In the CSL specification there is a standard variable "dimensions" = Physical (e.g. size) or temporal (e.g. running time) dimensions of the item
However there seems to be no Item Type available for incorporating the standard variable.
Additionally, in the Item Type "Journal Article" there is a seemingly non-standard variable "Extra" that, to me, is not possible to include in a custom format style.
A Custom Item Type creation tool might help.
It can be used in any item type by using
dimensions: 123cm
in the Extra field.The Extra field is CSL note
record title, name of collection or fonds, catalogue reference or internal identifier code, repository, institution.
You can add archival records of any item type (manuscript, document, letter, etc.) with the corresponding fields:
record title = title
name of collection or fonds =
archive_collection: Colection
in the Extra fieldcatalogue reference or internal identifier code = loc. in archive
repository = archive
institution =
archive-place: Institution
in the Extra field.Archive Collection and Archive Place are very likely going to be added to Zotero in the future -- in the meantime use the codes above, which will get migrated from the Extra field to proper fields once those exist.
I don't need anything fancy, but an option for musical scores would be great. Or even the possibility to edit contributor options.
Categorizing scores as audio recordings gives me the option to log composer and librettist, but then I lose publishing data so that's fairly useless.