Hello Nate,

I see your point, but I actually had the opposite experience when creating an XForms-based MODS editor. Having seven repeating date elements with all the attributes attached to them in 3.4 slowed my form for <originInfo> down to a standstill. Repeating one date element with an extra attribute would have solved the problem. However, I found other ways to reduce the processing load, so it is not an issue any more.

From the point of view of XPath, including an attribute as filter in a path as opposed to targeting an extra element name makes no material difference with regard to processing in the framework I use (index-based XQuery). Which kind of processing do you use at Library Services?

Conversely, when creating searches, all seven (actually, eight) date elements have to be indexed separately and aggregated for search in a field which for the library user is presumably simply labelled "Date". Again, this is no major problem - after all, you do not write a new search module every day.

The issue is mainly aesthetic.

Cheers,

Jens

On Feb 8, 2013, at 3:55 PM, "Trail, Nate" <[log in to unmask]> wrote:

> While I agree that consistency would be nice, from a processing point of view, the more unique element names are easier to digest than having to interrogate an attribute (which is also in many other places all through the document, so you better be looking at the right one in your code) to figure out what data element this is.  Although it makes the schema simpler, it makes processing the data more complicated.
> 
> My $.02. is that I'd prefer the opposite, or no change.
> 
> Nate
> 
> ---------------------------------------------------------------
> Nate Trail
> ---------------------------------------------------------------
> Network Development and MARC  Standards Office
> Technology Policy Mail stop 4402
> Library Services 
> Library of Congress 
> 202-707-2193
> [log in to unmask]
> 
> 
> 
> 
> -----Original Message-----
> From: Metadata Object Description Schema List [mailto:[log in to unmask]] On Behalf Of Jens Østergaard Petersen
> Sent: Friday, February 08, 2013 3:06 AM
> To: [log in to unmask]
> Subject: [MODS] date types
> 
> Hello,
> 
> In MODS, @type is used to subcategorize. We don't have <personalName> and <corporateName> and so on - and lucky for that.
> 
> Dates are the only exception. In <originInfo> we have the long list of <dateIssued>,  <dateCreated>,  <dateCaptured>,  <dateValid>,  <dateModified>,  <copyrightDate>, and <dateOther>.
> 
> If the design principles used elsewhere in MODS were followed, we would instead have one <date> element with a @type attribute that took the values "issued",  "created,  "captured,  "valid,  "modified",  "copyright, and "other". 
> 
> While this does not create major problems, I am curious to know why this decision was taken and if changes are being considered.
> 
> I have another question relating to typing dates:
> 
> In <part>, there is a <date> element. It is used for instance to record that a certain volume of a periodical belongs to a certain year, as for example in "Vol. 44, No. 3 (1999), pp. 13-17." Periodicals are not seldom behind schedule and it happens that this date is not the actual date of issue (the real date of issue may occasionally be recorded on the title page as well).
> 
> The <date> element is untyped, so there is no way to record this. I do not know which concrete value a librarian would use if it were possible, but I assume that one can be formulated. 
> 
> Needless to say, my suggestion is that a coming version of MODS uses a typed <date> element throughout.
> 
> Best,
> 
> Jens