Page Comparison

...

Action: Create a date display entry module to add on to CollectionSpace which can generate display texts.

Update 07 Sept 2010: A prototype has been created for this module, based on the specification included in the slides above. 

Update 18 Nov 2010: Sample screen shots will be added to this page to demonstrate how the prototype works.

Examples:

Here are a few examples of the prototype. Note that dates are not checked for correctness against a calandar, although boundaries for day and month are checked.

1. Date: Entering a year and segment.

Image Added

2. Date : If day or month are entered, then 'Segment' is unselectable.

Image Added

3. Period

Image Added

4. Before (or After) : There's a default value for calculating 'Earliest Date' but it can be overridden.

Image Added

5. Century

Image Added

6. Century by year (like Century, but a different display format)

Image Added

2. In the current system date display text is sometimes more detailed than the date ranges.

...

Action: Try to provide a means for users to enter month (and seasons) in a way which the current system does not.

3. CollectionSpace date format does not have room for some SMK date information. 

The datetype and dateextent fields from the current system describe two sets of strings which are used to help the user generate a display text. If we don't save this data, we cannot present the user with the expected user interface when editing data.

Action: We will not store this data. User can create a new date if they want to edit the old one via our interface extension.

4. Representation of dates in the current system.

Dates Representation of dates in the current system.

Dates are stored in a table represented by the following columns:

• id (integer : unique identifier)
• gbdatedisplay (String: English display text translation)
• datetype (Controlled list : Date, Before, After, Circa, Period, Century, Decade, Millenium, CenturyByFirstYear)
• dateto (integer: Latest date)
• datefrom (integer: Earliest date)
• dateextent (Controlled list : 1st half, 2nd half, 1st quarter, 2nd quarter, 3rd quarter, 4th quarter, beginning of, end of, middle of)
• datedisplay (String: Danish display text )

Date timestamps (dateto and datefrom) stored in the current system are represented as integers, in such a way that 0 = 30.12.1899, 1 = 31.12.1899 etc. (This is the same way dates are represented in most spreadsheets such as Open Office Calc and MS Excel so these programs can be used to quickly examine dates exported from the current system).5. Recent dates have been staightforward to convert, but ancient dates have been more problematic. So far, the most successful method for converting these has been the Java Jodatime library (using its default ISO chronology). The JDT Calendar library resulted in errors (by insisting upon a Gregorian/Julian chronology which couldn't be properly reconfigured and didn't match the representation of our data). However, with dates pre 100AD we still have conversion problems and are awaiting input from the implementers of our current system.

4. Mapping to CollectionSpace date format.There is no explicit mapping to the SMK date format described in Kim's mapping spreadsheet. The decision has been taken to use the Date - earliest/single,  Date - latest and Date text fields to represent all SMK date information (examples are shown below)

The current (frequently changing) plan is to map all current fields into Collectionspace. The datetype and dateextent fields (see above) from the current system describe two sets of strings which are used to help the user generate a display text. By mapping these to the 'certainty' and 'qualifier' fields we can present the user with the expected user interface when editing data. It remains to be seen if this constitutes misuse of the CS schema.

Below are some examples. Note: This mapping is probably based on a misunderstanding of the CS schema especially the earliest/latest dates, which here a interpreted as 'eariest/latest possible' dates.