Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dating attributes in the medieval catalogue #177

Open
holfordm opened this issue Sep 3, 2018 · 3 comments
Open

dating attributes in the medieval catalogue #177

holfordm opened this issue Sep 3, 2018 · 3 comments
Assignees
Labels

Comments

@holfordm
Copy link
Collaborator

holfordm commented Sep 3, 2018

Since the dates given in the medieval catalogue are almost all using the Julian calendar, the way they are currently expressed using the TEI dating attributues isn't strictly correct (since TEI assumes the Gregorian calendar). 'Correct' practice would be something like that recommended by epidoc (http://www.stoa.org/epidoc/gl/latest/supp-historigdate.html).
My questions are:

  • how significant do you think this is (is it worth making any changes?)
  • if we did want to make changes should it be done by using the "when-custom" etc. attributes or just with a statement in the ODD that dates are Julian unless otherwise specified?
@ahankinson
Copy link
Contributor

ahankinson commented Sep 3, 2018

@when-custom seems very strange...

Reading the TEI specs, they have:

<date calendar="#julian" when="1732-02-22"> Feb. 11, 1731/32, O.S.</date>

The usage, though, isn't very clear:

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.datable.html

"Note that the calendar attribute (unlike datingMethod defined in att.datable.custom) defines the calendar system of the date in the original material defined by the parent element, not the calendar to which the date is normalized."

Which, through the example they provide, suggests that you would still capture the Gregorian date in the @when, but the Julian date would be captured as the textual content.

Since most software will expect Gregorian dates, can we use the #julian value for @calendar to capture source material values, but normalize them to Gregorian dates in @when?

If so, I would expect this to be added somewhere in each TEI record:

<calendarDesc>
 <calendar xml:id="julian" target="https://en.wikipedia.org/wiki/Julian_calendar">
  <p>Julian calendar (as defined by Wikipedia)</p>
 </calendar>
</calendarDesc>

Or just:

<date calendar="https://en.wikipedia.org/wiki/Julian_calendar" when="1732-02-22"> Feb. 11, 1731/32, O.S.</date>

See: http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-calendar.html

@andrew-morrison
Copy link
Contributor

What is the aim:

  1. To be able to display Julian dates on the manuscripts pages?
  2. To stop having to convert to Gregorian for in @when attributes when the source is Julian?
  3. To encode Julian dates alongside the Gregorian?
  4. Convert everything to Julian?

@holfordm
Copy link
Collaborator Author

holfordm commented Sep 5, 2018

The aim (I think) would be to improve the interoperability / machine readability of the data by either making it clear that our dates (attributes and text) are Julian unless otherwise specified or as AH suggests by converting the values of the dating attributes (but not the text) to Gregorian dates. AFAIK, the dates displayed in the catalogue are already almost all Julian (just not labelled as such).
The thought of converting Julian dates to 'proleptic Gregorian' dates in the attributes makes me nervous, maybe it can be done programmatically, but the use of -custom attributes with @dating-method looks simpler to me - it would just be a lot of global changes (wouldn't it?).
It would be interesting to know how this issue affects the other catalogues, e.g are the conversions from Hebrew and Islamic calendars in Fihrist and Genizah really to Gregorian for pre-1582 dates?
It should probably also be stressed that the actual impact on the data would probalby be very small - it would only affect mss with exact dates, and probably only a veyr small number of those would change their years.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants