Closed bwiernik closed 4 years ago
Yes, should be done as suggested.
In the current situation there's indeed not much use for a variable container
alongside container-title
. But, I was contemplating a bit about our the current flat datamodel and how this could be made more flexible.
For example:
- id: doeTitleEssay
author:
- family: Doe
given: John
container-author:
- family: Doe
given: John
container-title: Collected Essays
title: Title of the essay
translator:
- family: Doe
given: Jane
type: chapter
Is translator
on the same level as title
, or with container-title
? In other words, has the translator translated the essay or the whole book? Impossible to tell here.
But let's change the data model:
- id: doeTitleEssay
author:
- family: Doe
given: John
container:
title: Collected Essays
author:
- family: Doe
given: John
title: Title of the essay
translator:
- family: Doe
given: Jane
type: chapter
It's absolutely clear now that the we have the essay has been authored by John Doe, translated by Jane Doe, and that the container also has a author.
Or, if the whole book has been translated by Jane Doe:
- id: doeTitleEssay
author:
- family: Doe
given: John
container:
title: Collected Essays
author:
- family: Doe
given: John
translator:
- family: Doe
given: Jane
title: Title of the essay
type: chapter
In such a model, there would be no need for duplicate variables like container-author
/author
, container-translator
/translator
. Also, this could be adapted to cover other needs as well, like adding original publishing information, information about a reviewed book, etc. Think:
- id: doeTitleEssay
author:
- family: Doe
given: John
title: A review essay
container:
title: Collected Essays
author:
- family: Doe
given: John
translator:
- family: Doe
given: Jane
original:
publisher:
publisher-place:
reviewed:
title: The reviewed essay
author:
- family: Bar,
given: Foo
type: chapter
Thinking about the variables that could be hierarchical nodes:
container
collection
original
reviewed
volume
event
issue
short
I counted them once based off the 1.0.1 variables, 20 of those could be reduced to 8 (though I may have missed some nuance). Just copying:
And if we get volume-title
, volume
and issue
would be good too.
Archive could be something like below if we're really keen on reusing variables, though I guess it's a completely different kind of locator.
archive:
title: Some Archive
place: Somewhere St, City
locator: Box 1234
Is the CSL data schema considered part of the specification? If not, processors could just opt into processing linked data.
Also, there's no use for container-date
then? I thought that was what this variable was meant to mean.
Also, there's no use for container-date then? I thought that was what this variable was meant to mean.
I’m not sure if that was the intention (I’m thinking not or it would have been called container-date?).
In any event, I’m not sure what the use of container-date
would be. If you are thinking about something like an article republished in a book, so that container-date
would be the book date and issued
the original date, then we would expect to sue original-date
instead (and issued
for the book).
How is "container" used in existing styles?
It's not. It's only used in a single style where it's in a list of all the date variables.
I am not sure what the intended function of
container
is, but it seems clearly misclassified as a date variable. I don't see its value alongside the variouscontainer-
variables. I suggest it be deprecated and eventually removed.(Mentioned here: https://github.com/citation-style-language/csl-evolution/issues/9)