Conversation between Megan and Aron on 2009-10-30 in IRC about dates in object and procedural records:
...
.
This is related, in part, to services work on implementing free text dates in CSPACE-2418.
Summary
Procedural records
When museum staff and other system users enter dates into new procedural records:
- They will typically be entering full calendar dates (e.g. 2010-08-22), not dates and times.
- A date picker, such as the Fluid date picker, can likely accommodate this.
- Combinations of dates and times (e.g. timestamps) will likely be used mostly for auditing, to identify when records are created or modified, rather than during data entry into procedural records.
- There will often be two dates that represent an implicit range, such as a start and end date for a loan or a conservation activity.
- Logic will need to understand that these ranges exist. Megan: "If I want to see all the items that were on loan last year [e.g. 2008], and I have an object that went out in 2006 and is due back in 2011, I want it to come up."
Object records
When system users enter dates into object records:
- See Date Schema for more details on the general form of date fields in object records.
- The form of these dates may vary widely. One example, referred to by Megan: Categories for the Description of Works of Art: Creation Date.
- Megan: "Institutional preference will determine what degree of specificity is added to dates. At MMI, we use years for creation date, but the Walker may chose a date and time for a performance piece."
- Expressions of uncertainty, and qualifiers related to accuracy, will frequently accompany dates.
- Megan: "A date picker is inappropriate for object dating."
- UI may need to be developed to handle date entry.
- More generally, we'll need to determine how to accommodate entry of data for various object record-related dates that may either represent date-type data, which can be stored and processed as calendar dates, or data that is difficult or impossible to parse as such.
Relevant IRC Transcript(s)
[11:22am] aronr: aronr: this is about dates in object records
[11:23am] aronr: i'm assuming, for now - always a dangerous thing - that dates in procedural records represent either the date of the activity (intake, acquisition, loan)
[11:23am] aronr: or dates of significance to the activity (e.g. a return date)
[11:23am] aronr: and that those are primarily full calendar dates
[11:24am] aronr: although audit trails may record timestamps for record creation and modification
[11:24am] aronr: is that accurate?
[11:24am] mmiforbes: In a nutshell, yes.
[11:24am] aronr: ok, at least to one order of simplification - great!
[11:24am] aronr: so ... for object records
[11:24am] aronr: it looks like we have a melange of dates
[11:24am] aronr: some of which may differ from others in what may typically be entered, or in a user's expectations about what they may want that field to accommodate
[11:25am] mmiforbes: (also, yes+ to the audit trail...those should always be date/timestamped for any activity relating to a record, these should not be able to be changed by a users)
[11:25am] aronr: understood
[11:25am] aronr: i'm looking at the (perhaps old, as you mentioned, but very thorough)
[11:25am] aronr: http://wiki.collectionspace.org/download/attachments/7208965/object_cataloging2.jpg
[11:25am] aronr: image of object cataloging
[11:26am] aronr: record components
[11:26am] mmiforbes: Back to procedural records, I would add that a range of calendar dates would also be appropriate, e.g. this thing was on loan from 8/22/75-9/5/77, or this thing was in the conservation lab from 10/23/09 to 10/30/09.
[11:26am] aronr: ok, good
[11:26am] mmiforbes: ok, back to objects!
[11:26am] aronr: would this be accommodated by, say, two date fields - a beginning and ending date for the range? (switching tracks back to procedural for a moment)
[11:26am] mmiforbes: yep, two fields would be apprpriate
[11:27am] aronr: and some way of selecting between either a single date or a date range?
[11:27am] aronr: (and if so, do we have that currently or envisioned in ui and schema?)
[11:27am] aronr: sorry ... i'm making this FAR too complicated
[11:28am] aronr: we usually have a 'return date' field
[11:28am] mmiforbes: no, I think I am...
[11:28am] aronr: as in intakes
[11:28am] aronr: and loans
[11:28am] aronr: that would accommodate the 'range thing'
[11:28am] aronr: yes?
[11:28am] mmiforbes: the range would sort of be implicit because there are two fields
[11:28am] aronr: understood
[11:28am] aronr: so we don't need some sort of construction - at least in procedure records - to accommodate date ranges - where ranges are possible, the schemas have two date fields
[11:28am] mmiforbes: difficulty: If I want to see all the items that were on loan last year, and I have an object that went out in 2006 and is due back in 2011, I want it to come up.
[11:29am] mmiforbes: Correct, where a range is possible, two fields should be present (start and end).
[11:29am] aronr: understood ... that's a burden for logic, not for schema?
[11:30am] mmiforbes: The schema accomodates start/end, the logic needs to know that there's a relationship
[11:30am] aronr: (the 'which items were on loan last year' query, that is)
[11:30am] aronr: good, i think we're in accord
[11:30am] mmiforbes: phew
[11:30am] aronr: in our understanding of this
[11:30am] aronr: great!
[11:30am] aronr: now back to objects
[11:31am] aronr: from what I can see, and I'm looking at this very naively no doubt
[11:31am] aronr: in the extensive set of fields that describe an object in various ways
[11:31am] aronr: there are a number of date fields
[11:31am] aronr: some of which may typically - as you pointed out - accommodate a year, not a calendar date
[11:31am] mmiforbes: I pulled them out into a separate schema, if it helps to not have to look at the giant cataloging wireframe:
[11:31am] aronr: and perhaps are qualified by certainty
[11:32am] mmiforbes: http://wiki.collectionspace.org/display/collectionspace/Date+Schema
[11:32am] aronr: good, thanks!
[11:32am] mmiforbes: So, institututional preference will determine what degree of specificity is added to dates.
[11:32am] aronr: we've been looking at the same thing - and this schema is really helpful that way
[11:32am] aronr: here's my question
[11:32am] mmiforbes: At MMI, we use years for creation date, but the Walker may chose a date and time for a performance piece.
[11:32am] aronr: in the wireframes, there are frequent references - for date fields
[11:33am] aronr: understood and we're converging on a common question
...
[11:33am] aronr: which from what I can see, typically is either a date picker, a time picker, or a date and time picker
[11:34am] aronr: probably can't accommodate pre-Gregorian dates (a wild assumption on my part)
[11:34am] mmiforbes: I would argue that the date picker is inappropriate for object dating.
[11:34am] aronr: and may or may not be able to accommodate selection of a single year
[11:34am] aronr: understood and agreed
[11:34am] aronr: so we'll probably need to do some date recognition and handling
[11:35am] aronr: which means understanding and accommodating various diverse formats
[11:35am] aronr: and saying "huh?" when we receive something we don't recognize
[11:35am] aronr: and/or giving the user some way of bypassing this restraint
[11:36am] mmiforbes: Agreed.
[11:36am] aronr: without inserting unrecognizable crud into a structured date field
[11:36am] aronr: does this mean we will need to come up with a UI convention for handling non-date-picker entry of dates and times?
[11:37am] aronr: and decide among the teams where date validation logic comes in, which could be at one layer, or more than one?
[11:38am] mmiforbes: Yes to UI convention for entry of dates and times.
[11:39am] aronr: ah ... thanks
[11:39am] aronr: i think that's all for now
[11:39am] aronr: do you have anything I should think about further, regarding dates and times?
[11:39am] mmiforbes: CDWA also has a nice section on date entry, which could be helpful as we think of UI conventions.
[11:39am] aronr: ok, great! That's exactly the type of thing I was hoping for - will check that out.
[11:40am] mmiforbes: Time isn't dealt with too often, but again, if we're dealing with newer media forms, it's going to be an issue. I'll ask Robin at the Walker if they can contribute some use cases around this.
[11:40am] aronr: ok, thanks
[11:40am] mmiforbes: CCO (and CDWA) recommend ISO 8601:2004, but I think that's just for numeric representations of date.
[11:41am] mmiforbes: W3C XML Schema Part 2: Datatypes is also a popular reference.
[11:41am] aronr: so is it correct to assume that, in most instances, the most atomic portion of a date that a user of the system might see is a calendar date, representing a full date?
[11:41am] aronr: good - the XML datatype is based on a profile of ISO 8601, from what I recall (from hazy memory)
[11:42am] mmiforbes: Yes to calendar date - that will be sufficient for most.
[11:42am] aronr: ok, great
[11:42am] mmiforbes: cool. I'll talk to the designers about the UI implications.
[11:42am] aronr: don't mean to keep you further - anything else we should know/think about in this space?
[11:42am] aronr: thanks - re talking about UI implications!
[11:43am] mmiforbes: no problem - I think we should return to our respective corners and then regroup when we've had a chance to discuss with our respective teams
