# update on particle, date patches
**URL:** https://discourse.citationstyles.org/t/update-on-particle-date-patches/757
**Category:** CSL Development
**Created:** [September 6, 2009, 10:20pm UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757 "2009-09-06T22:20:18Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)
#### Post date: [September 6, 2009, 10:20pm UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757/1 "2009-09-06T22:20:18Z")
So I’m still lost on these two patches.
particle: not sure where we ended up with the discussion on the
parameters, nor why the “invert” thing got thrown in. I’ll wait on
Rintze’s proposed spec language and revised patch before doing
anything.
date: as I said, I don’t understand the “other” problem, and Frank
seemed not to think this is that critical an issue, so my druthers is
to leave it out.
Bruce
---
### Author:  [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)
#### Post date: [September 6, 2009, 11:35pm UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757/2 "2009-09-06T23:35:01Z")
> So I’m still lost on these two patches.
>
> particle: not sure where we ended up with the discussion on the
> parameters, nor why the “invert” thing got thrown in. I’ll wait on
> Rintze’s proposed spec language and revised patch before doing
> anything.
>
> date: as I said, I don’t understand the “other” problem, and Frank
> seemed not to think this is that critical an issue, so my druthers is
> to leave it out.
By leaving it out, do you mean to leave out the “other” date-part?
That would be our choice, too.
---
### Author:  [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)
#### Post date: [September 6, 2009, 11:36pm UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757/3 "2009-09-06T23:36:25Z")
> > So I’m still lost on these two patches.
> >
> > particle: not sure where we ended up with the discussion on the
> > parameters, nor why the “invert” thing got thrown in. I’ll wait on
> > Rintze’s proposed spec language and revised patch before doing
> > anything.
> >
> > date: as I said, I don’t understand the “other” problem, and Frank
> > seemed not to think this is that critical an issue, so my druthers is
> > to leave it out.
>
> By leaving it out, do you mean to leave out the “other” date-part?
> That would be our choice, too.
(We’ll also need a day-month form for localized dates, but I don’t
think that’s been proposed yet.)
---
### Author:  [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)
#### Post date: [September 6, 2009, 11:39pm UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757/4 "2009-09-06T23:39:07Z")
No. The use case for the other part is absolutely clear (effectively,
sub-year components which are “other” than months and days), and I
don’t see any practical problem with retaining it.
Bruce
---
### Author:  [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)
#### Post date: [September 7, 2009, 12:03am UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757/5 "2009-09-07T00:03:57Z")
> > > So I’m still lost on these two patches.
> > >
> > > particle: not sure where we ended up with the discussion on the
> > > parameters, nor why the “invert” thing got thrown in. I’ll wait on
> > > Rintze’s proposed spec language and revised patch before doing
> > > anything.
> > >
> > > date: as I said, I don’t understand the “other” problem, and Frank
> > > seemed not to think this is that critical an issue, so my druthers is
> > > to leave it out.
> >
> > By leaving it out, do you mean to leave out the “other” date-part?
> > That would be our choice, too.
>
> No. The use case for the other part is absolutely clear (effectively,
> sub-year components which are “other” than months and days), and I
> don’t see any practical problem with retaining it.
Text that is not captured in the date elements by the parse can and
should be rendered. The point of dropping “other” from the schema
wouldn’t change that. It’s just that because the position of the
“other” element is fixed, and because its content is a dumb string
(and therefore not safe for formatting), there is no need to include a
date-part for it in the schema.
---
### Author:  [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)
#### Post date: [September 7, 2009, 12:19am UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757/6 "2009-09-07T00:19:23Z")
OK, I understand that. But that would mean we’d disallow applying
formatting (bold and such) to these components.
Bruce
Bruce
---
### Author:  [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)
#### Post date: [September 7, 2009, 1:26am UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757/7 "2009-09-07T01:26:13Z")
> > > > > So I’m still lost on these two patches.
> > > > >
> > > > > particle: not sure where we ended up with the discussion on the
> > > > > parameters, nor why the “invert” thing got thrown in. I’ll wait on
> > > > > Rintze’s proposed spec language and revised patch before doing
> > > > > anything.
> > > > >
> > > > > date: as I said, I don’t understand the “other” problem, and Frank
> > > > > seemed not to think this is that critical an issue, so my druthers is
> > > > > to leave it out.
> > > >
> > > > By leaving it out, do you mean to leave out the “other” date-part?
> > > > That would be our choice, too.
> > >
> > > No. The use case for the other part is absolutely clear (effectively,
> > > sub-year components which are “other” than months and days), and I
> > > don’t see any practical problem with retaining it.
> >
> > Text that is not captured in the date elements by the parse can and
> > should be rendered. The point of dropping “other” from the schema
> > wouldn’t change that. It’s just that because the position of the
> > “other” element is fixed, and because its content is a dumb string
> > (and therefore not safe for formatting), there is no need to include a
> > date-part for it in the schema.
>
> OK, I understand that. But that would mean we’d disallow applying
> formatting (bold and such) to these components.
Yes. If there were a demand for seasons to be set in italics (for
e.g.), we could refine the date parse, and then introduce an element
that specifically applies to season names.
---
### Author:  [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)
#### Post date: [September 7, 2009, 2:12am UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757/8 "2009-09-07T02:12:44Z")
> So I’m still lost on these two patches.
>
> particle: not sure where we ended up with the discussion on the
> parameters, nor why the “invert” thing got thrown in. I’ll wait on
> Rintze’s proposed spec language and revised patch before doing
> anything.
I’ll leave the talking to Rintze. But on the “invert” item, this is
just a renaming of name-as-sort-order. We reasoned that keeping it as
name-as-sort-order would be misleading, once the name-part sequence
for display was decoupled from that used for sorting.
---
### Author:  [@Rintze\_Zelle](https://discourse.citationstyles.org/u/Rintze_Zelle)
#### Post date: [September 7, 2009, 12:30pm UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757/9 "2009-09-07T12:30:57Z")
I don’t think so. It would make sense to apply any formatting set on cs:date
to these unparsed affixes. For the ‘normal’ date-parts (year, month, day),
the formatting set to cs:date can be overridden by applying formatting
attributes on the cs:date-part elements.
Rintze
---
### Author:  [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)
#### Post date: [September 7, 2009, 2:05pm UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757/10 "2009-09-07T14:05:47Z")
…
> > OK, I understand that. But that would mean we’d disallow applying
> > formatting (bold and such) to these components.
>
> I don’t think so. It would make sense to apply any formatting set on cs:date
> to these unparsed affixes.
Just a clarification (for purposes of the spec and such): “other”
parts are not necessarily exactly “unparsed” nor are they “affixes”.
In my implementation, dates have to conform to a strict data-type, and
the “other” part is defined (borrowing from RIS, BTW).
So I think we need to be explicit about the “other” content.
Bruce
---
### Author:  [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)
#### Post date: [September 7, 2009, 2:17pm UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757/11 "2009-09-07T14:17:00Z")
> …
>
> > > OK, I understand that. But that would mean we’d disallow applying
> > > formatting (bold and such) to these components.
> >
> > I don’t think so. It would make sense to apply any formatting set on cs:date
> > to these unparsed affixes.
>
> Just a clarification (for purposes of the spec and such): “other”
> parts are not necessarily exactly “unparsed” nor are they “affixes”.
> In my implementation, dates have to conform to a strict data-type, and
> the “other” part is defined (borrowing from RIS, BTW).
>
> So I think we need to be explicit about the “other” content.
It would be helpful to know what an other element can and cannot contain.
---
### Author:  [@Rintze\_Zelle](https://discourse.citationstyles.org/u/Rintze_Zelle)
#### Post date: [September 7, 2009, 2:16pm UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757/12 "2009-09-07T14:16:53Z")
How would that work in real life? IMHO, the benefits of having a "unparsed"
prefix and suffix instead of a single “other” date-part seem to be:
- Stuff like “circa 2000 (?)” with two “other” parts would be supported
- The position of the “other” date-part doesn’t have to be set in the styles
(i.e. before or after the main date, “circa 2000” or “2000 (?)”)
- Current styles won’t have to be changed
Rintze
---
### Author:  [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)
#### Post date: [September 7, 2009, 2:33pm UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757/13 "2009-09-07T14:33:33Z")
A string.
“2000///Fall”
… where “Fall” is the other string.
Note: I’m not saying this has to be enforced in CSL; just saying we
don’t want to introduce language that suggests otherwise (no pun
intended).
Bruce
---
### Author:  [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)
#### Post date: [September 7, 2009, 2:35pm UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757/14 "2009-09-07T14:35:42Z")
In my implementation at least: “2000~”. So “circa 2000” won’t be valid.
Bruce
---
### Author:  [@Rintze\_Zelle](https://discourse.citationstyles.org/u/Rintze_Zelle)
#### Post date: [September 7, 2009, 2:48pm UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757/15 "2009-09-07T14:48:48Z")
Are you hoping that Zotero will convert “circa 2000” to “2000~” for you? Or
should the content of the date-field in Zotero be constrained to strings
that can be parsed (like “2000~”)? Or will "circa " just be discarded when
the “circa 2000” string is send to the CSL processor (yielding “2000”)?
---
### Author:  [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)
#### Post date: [September 7, 2009, 3:04pm UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757/16 "2009-09-07T15:04:16Z")
> Are you hoping that Zotero will convert “circa 2000” to “2000~” for you?
Yes and no.
Yes, I think Zotero should be a little more strict on date entry,
storage, export.
Yes, I think part of that means it should explicitly support approximate dates.
No, I don’t care that much personally (and part of the reason I’m
writing the Python version is because I don’t always want to use
Zotero).
> Or should the content of the date-field in Zotero be constrained to strings
> that can be parsed (like “2000~”)? Or will "circa " just be discarded when
> the “circa 2000” string is send to the CSL processor (yielding “2000”)?
That’s up to Dan and Simon, but I don’t think it’s too much to ask
them to send “2000~” (nor to store and export it that way).
---
### Author:  [@Robert\_Knight](https://discourse.citationstyles.org/u/Robert_Knight)
#### Post date: [September 7, 2009, 3:53pm UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757/17 "2009-09-07T15:53:52Z")
> Yes, I think Zotero should be a little more
> strict on date entry, storage, export.
> Yes, I think part of that means it should explicitly support approximate dates.
What do you think should be done on import though? Unfortunately (or
fortunately depending on your point of view) most
reference management software treats its data just as a bunch of
labeled fields which may contain arbitrary strings. If they
pipe that data through CSL and it gets lost in the process then they
will probably blame the CSL tool.
I imagine if you try to capture or explicitly deal with all the little
details people might want to include in these fields then
the spec could get very large.
Regards,
Robert.2009/9/7 Bruce D’Arcus \<@Bruce\_D\_Arcus1\>:
---
### Author:  [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)
#### Post date: [September 7, 2009, 4:31pm UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757/18 "2009-09-07T16:31:55Z")
> > Yes, I think Zotero should be a little more
> > strict on date entry, storage, export.
> > Yes, I think part of that means it should explicitly support approximate dates.
>
> What do you think should be done on import though?
There’s a chicken-and-egg problem here, and a reasonable question of
where (or whether) the normalization happens.
“Import” from where? If it’s from MARC data, you can parse c. and
original dates.
> Unfortunately (or
> fortunately depending on your point of view) most
> reference management software treats its data just as a bunch of
> labeled fields which may contain arbitrary strings.
I’m not so sure.
RIS dates are structured: YYYY/MM/DD///other.
> If they pipe that data through CSL and it gets lost in the process then they
> will probably blame the CSL tool.
And if it can’t sort their bibliography correctly, they’ll probably
also blame the CSL tool.
> I imagine if you try to capture or explicitly deal with all the little
> details people might want to include in these fields then
> the spec could get very large.
I’m not willing to support every conceivable little eccentricity, but
I am willing to support:
approximate dates
ranges
BC
All of these are covered in the new EDTF effort from the LOC:
[http://www.loc.gov/standards/datetime/](http://www.loc.gov/standards/datetime/)
I’m also happy to support original dates (which we already have).
The only other thing is the “other” dates in RIS and CSL (the primary
use case being “Fall” and such).
Doesn’t that cover 99% of use cases?
Bruce
---
### Author:  [@Robert\_Knight](https://discourse.citationstyles.org/u/Robert_Knight)
#### Post date: [September 7, 2009, 4:41pm UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757/19 "2009-09-07T16:41:20Z")
> “Import” from where? If it’s from MARC data, you can parse c. and
> original dates.
I was referring to your comments about whether Zotero (or similar
software) should store and export things like ‘circa’
in dates.
> Doesn’t that cover 99% of use cases?
It covers everything that I can think of. As always I expect that
there will be a researcher somewhere who has some particular
requirement that is very important to them that we haven’t thought of.
I think that the list of ‘date features to support’ you mentioned is
a sensible
place to draw the line though.
Regards,
Robert.2009/9/7 Bruce D’Arcus \<@Bruce\_D\_Arcus1\>:
---
### Author:  [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)
#### Post date: [September 7, 2009, 6:05pm UTC](https://discourse.citationstyles.org/t/update-on-particle-date-patches/757/20 "2009-09-07T18:05:56Z")
OK, let’s talk data and data exchange.
Zotero’s primary export format is RDF, which they’re now upgrading to
supporting BIBO. In either case, really, Dublin Core is the date
representation.
Let’s take a simple turtle representation of this RDF. We could do:
[http://example.org/1](http://example.org/1) a bibo:Article ;
dcterms:issued “200 BC” .
…or:
[http://example.org/1](http://example.org/1) a bibo:Article ;
dcterms:issued “circa 1345” .
… which are worthless (for sorting ,at least) without additional
processing, which may not be entirely reliable.
Or we could do:
[http://example.org/1](http://example.org/1) a bibo:Article ;
dcterms:issued "-0200"xsd:gYear .
…or:
[http://example.org/1](http://example.org/1) a bibo:Article ;
dcterms:issued "1345~"loc:edft .
These dates will sort correctly without modification,
We can also do this in HTML with RDFa …
c.1345
… where we start to allow full round-tripping of data, without funky
and unreliable text parsing.
Bruce