Firstly, thanks for the reply.
> But then why supply the whole value? Why not just supply 2007-02? All of the
> formats - w3cdtf, iso8601, and marc -- allow this.
The reason I can't just supply 2007-02 is because in the backend MODS is
being indexed in a relational database in a 'datetime' field which even if
you insert '2007-02' would store it as '2007-02-01'. It is necessary to
store it as a datetime field so I can do datetime sorting, searching etc. If
I was storing just 2007-02 in a string that would be simple, but then I
couldn't do sorting or date comparisons which are very valuable in my
application using MODS.
So system requires I store a full 2007-02-01 full date at least. If the
granularity of a date in a MODS element is really only 2007-02 (eg
publication date of a journal is only year/month, not day) by storing it as
2007-02-01 I can't then store any information about the fact that the
granularity should only stretch that far in the current MODS schema.
If I had a granularity attribute in MODS for each element that stores a date
then my database layer can still store the full date 2007-02-01 do sorting
etc, but my application layer will know to only show to the user in the
presentation of this record the value '2007-02-01'. I could store this
granularity outside of MODS, but it would be much cleaner and simpler to
store it as an attribute against the date value element itself.
I know this is an implementation issue and MODS might not be about practical
implementation but I think date granularity is still useful and others will
come up against this problem.
I hope my explanation makes sense to you. I am only suggesting this be an
optional attribute of course as some MODS users will not care about date
sorting or indexing MODS in a relational database - but surely many do.
Senior Library Systems Programmer
Library Technology Service
The University of Queensland, Australia QLD 4072
Telephone : (+61) (7) 3346 4337