Custom item types are planned for the medium term, but it is a very technically difficult problem, especially if users expect to be able to include such types in citations.

@bwiernik I think one possible solution to the very difficult problem you mention is to alias new names in the UI to types to existing types. That is, in the case of the OP who is citing tweets, these might be citeable as web pages, or they might be citeable as instant messages (tweet threads), or also as a forum post. However, it is likely that for Zotero users (and people in general) that tweet's exist as a separate mental 'category' and don't think or look to see how to categorize the content they are trying to cite. I know this has been my area of growth... thinking about the things I want to cite in terms of how they match the existing categories vs. how I am thinking about them.

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.

Building/sedgeway on @hughp3, I would propose the following: Add a new 'type' called 'generic'. The item panel would look like:

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.

Full-on, enthusiastic agreement about the need for this. Would the ability
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.

@juliakeelerpeck if that style would only be used by you or a very limited number of users, you can already implement that. If you put 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.

"Web page," "instant message" and "forum message" treat the whole tweet's text as a title, so they """Capitalize all the First Letters Except for the Prepositions and Articles."""

Other than that they're quite a good solution.

+1

+1.

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.

+1
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.

+1 for @hughp3 's suggestion specifically!

Custom fields are not going to be a particularly helpful way to get items cited properly (because at that point you'd also have to define their mapping to citation styles and modify the citation styles themselves).

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 field
catalogue 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 would love to have a Book Review type - It's neither a Book nor a Journal/Magazine Article, really.

While I'm not a member of the Zotero development team or a CSL specialist, I'd like to express my opinion on the request of this thread as far as I understand it - I have encountered similar questions in various contexts for more than a decade, I agree that one might want to distinguish precisely between objects that are not exactly the same (I see myself as rather detail-oriented person), but I feel that people often underestimate the consequences of "just create a new item type", or "fine, just let me create my own and I'll manage it locally" :-)

Indeed customizable types would be a game changer, but one that looks super difficult (if not impossible) to map with the very important requirements of the citation use case, i.e. "how am I supposed to cite this in a document". From my point of view, the most efficient strategy is to focus on the closest possible standard type, i.e. one that will be described using the same properties.

The purpose of the document (to present new scientific developments, or review the state of the art, or comment on a newly published book, or anything else...) has a very limited impact on that use case - whereas introducing a new non-standard document type has a dramatic effect: basically, no citation style will understand it. To put it another way, the publication venue (journal, book, web site, patent, whatever) matters more than the actual purpose of the document from a citation point of view, and proper citation in one of the thousands of possible citation styles is the main reason why reference managers such as Zotero exist in their current shape. I agree that it isn't an absolutely good reason (the existence of thousands of different styles is quite absurd), but it certainly protects the mental health of thousands (millions?) of authors all over the world. Supporting this very important use case consumes non negligible time and energy, and any significant change in the software must be evaluated with respect to that baseline. The Extra fields are an affordable way to add very specific information into the standard document types, even when they do not feel very elegant.

Personally, I think that the added value of custom document types doesn't compensate the newly created problems and the development cost. Is a book review published in a journal or magazine (a fairly frequent situation)? Then why shouldn't the tool treat it as a Journal/Magazine article?