First, let me thank you very much for all the work on this new CSL version 1.0.2 and the possibility for giving feedback!
There is a new proposed publication type “event” where I wanted to make two comments:
- There is already a variable with the name “event” such that it is not ideal to have the same label for a publication type. This could getting some confusion.
- In the CSL JSON schema this new publication type is missing.
In the CSL variable “event” the name of an event can be saved. Therefore, it might be better to change that to “event-name” which then would give us the possibility to use “event” for an individual publication type. However, this would then be a breaking change and therefore nothing we want to do in this minor version update.
1 Like
I had the same concern about the item type name. Bruce didn’t think it was much of an issue.
I’d rather not change the variable name at all. If you have a suggestion for a better type name, that would be great.
The impetus for this type was mainly museum exhibitions, but it could be used more broadly (e.g., for citations to whole conferences or meetings). I couldn’t come up with a better general term than ‘event’. Maybe occurrence, occasion, activity?
(I jokingly suggested “happening” or “shindig” as potential type names. 
)
1 Like
I am skeptical that we find another, equally suitable word for “event”.
However, do we really need the general term here? It originates AFAIS from “exhibition” which would be a good distinguishable label. The “hearing” has its own publication type now anyways.
If we need another event type then we could make that specific as well. We already distinguish several “article” types according if they appear in a journal, newspaper or magazine.
The two major things that come to mind would be exhibitions and conferences/symposia/meetings. Those have very similar citation needs. They pretty much differ only the creator type (curator vs organizer or chair). Hearing on the other hand has a very distinct citation pattern similar to legal cases.
But we already have other publication types where the fields will be very much the same, e.g. “entry-dictionary” and “entry-encyclopedia” seems to have exactly the same fields (at least if I look at the mapping from Zotero). And a “motion-picture” might also look the same as a “song” except for the creator types.
My impression is that publication types in CSL are quite specific, but on the other hand the fields try to be much more generic (e.g. all the different contexts where container-title is used).
I’d be okay with separate exhibition and conference/meeting items. (I think the latter would primarily appear on CVs, similar to grants.) What do you think @bdarcus?
1 Like
I think the fact that we didn’t earlier have a generic event type, before adding hearing, was a mistake.
But I also agree the “event” variable is a problem, even without this new type. I’m not even sure what that variable is for at this point. I guess the event related to a document; so kind of like a plain-text relation?
For the event variable:
I think @Philipp_Zumstein is right that this should really be event-title (“name” should be for people/creators IMO), but we don’t want to make backwards incompatible changes in 1.0.x releases.
Could we do something like introduce event-title and mark as equivalent/synonym to event (the variable) and mark the latter as deprecated, or is that very ugly?
1 Like
I think we could introduce a more meaningful variable for 1.0.2, mark event deprecated`, and remove in 1.1.
2 Likes
that’s exactly what I mean, yes
1 Like
One little wrinkle: this is related to the as yet unresolved “related” modeling discussion for 1.1.
In theory, it could be events get modeled also as relations; e.g.:
type: paper
title: Some Title
presentedAt:
type: event
subtype: conference
title: Conference Title
1 Like
I don’t think overlapping terms are as big a deal when we are talking about an a type of relation and an item type. If the event variable is renamed to event-title, then the meaning here is clear:
type: speech
title: A conference presentation:
related:
event:
type: event
genre: Conference
title: Conference title
If we did want a separate label for the type of relation, perhaps related-event or containing-event. presented-at might work too. I don’t know what other types of event relations there might be, so that would probably be fine.
A somewhat related question. Currently, we are inconsistent in whether number variables include -number or not. For example, chapter-number and collection-number but volume and issue. We currently are slated to add some more variables without -number in them for 1.0.2 (e.g., part, supplement, printing).
Since we are going to rename event, should we also rename these? I think it would be clearer to have volume-title and volume-number rather than volume-title and volume (the latter being a number).
I’ve been confused by this too, and tend to think we should fix it.
But I guess we’d want to make sure we can easily fix it in existing styles we upgrade for 1.1.
Edit: turns out this is easy:
<xsl:template match="//*/@variable[.='event']">
<xsl:attribute name="variable">event-title</xsl:attribute>
</xsl:template>
I’ve added a xslt-update branch to the schema repo to add these to csl-update.xsl.
Actually, could you possible update here on what variable names we need to update in the styles, @bwiernik, so I can just add them at once, and then merge?
These are the number variables:
variables.numbers =
"chapter-number"
| "citation-number"
| "collection-number"
| "edition"
| "first-reference-note-number"
| "issue"
| "locator"
| "number"
| "number-of-pages"
| "number-of-volumes"
| "page"
| "page-first"
| "part-number"
| "printing-number"
| "section"
| "supplement-number"
| "version"
| "volume"
(part-number, printing-number, supplement-number are new in 1.0.2; I pushed a commit to my PR making them -number in 1.0.2)
These are the title variables:
variables.titles =
"collection-title"
| "container-title"
| "original-title"
| "part-title"
| "reviewed-title"
| "title"
| "translated-title"
| "volume-title"
So:
-
volume to volume-number I think should change.
-
issue to issue-number probably
-
locator is an object, so clearer to leave without
-
edition, version, section are reasonably likely to be non-numeric, so we should leave these
-
page we’ve discussed making possible to contain other types of locators (e.g., column numbers), like locator, so I suggest we leave this (or discuss some other change).
-
number would perhaps better be labeled document-number. It is currently used both for document numbers (e.g., reports, patents, legislation, legal cases) and in Zotero for episode numbers on broadcasts. That creates some problems that could be addressed by understanding number to be a document number and an episode number to be page and/or chapter-number.
I don’t think that this XSLT rule is enough. For example have a look at testing more than one variable like, e.g.
<if variable="event version" type="speech dataset motion_picture" match="none">
I neglected to check that. Did you?
It should work, because the logic of the stylesheet is copy everything as is, except those with specific template matches.
If not, and you figure out how to fix it, let me know.
The problem is that with multiple variables your expression (='event') is not matching. The matching part needs to be less restrictive with some contains(). However, the real challenge is the replace then, because you cannot replace the attribute value completely but only parts of of. A quick search lead me to this https://stackoverflow.com/questions/15976297/in-xslt-replace-one-class-value-when-there-are-multiple-values which looks very similar and should be possible to adapt. Alternatively some small Python script might be in a lot of cases easier to do than XSLT.
However, the main problem is maybe, that the CSL styles are only one part. The other part CSL JSON data comes from a variety of sources which will not immediately (maybe also not within a year) switch to the new variables we want to introduce. Thus, I expect that we need to support the deprecated variables longer.
This could mean two direction: (1) either in the CSL styles handle the new variable besides the old (deprecated) variable, or (2) only in the implementations like citeproc-js have some mechanism to map any value from a deprecated variable into the new one before. I guess we have to start with (1) and look that (2) happens and then be very careful before stoping with (1).
1 Like
As there is currently no alias mechanism, maybe we should now consider adding one? So we could update styles to use the new terms, but preserve legacy compatibility.
1 Like