I should clarify:  I definitely wasn't advocating for anyone else to follow those practices; I was simply sharing them.  

I would assume that any consortium would have their own set of best practices, and that you'd want to adhere to those, first and foremost (in our case, we're not currently included in a larger consortium, so occasionally I've made use of what I've felt would be the simplest --and least verbose-- of solutions.  And, none of those decisions are irreversible).

I still wonder, though:  what's the point of marking any of the unitdates with type="inclusive", especially if those elements also contain a normal attribute?  They are either identified as bulk date ranges, or they aren't bulk date ranges, right? (I also admit that I initially took issue with calling something like "10/31/1921" an inclusive date...  though I suppose it still is inclusive of some sort of undefined start- and stop-time within that 24 hour time period).

So, though I agree that a "nothing means something" technique could be problematic, in this case I just don't think that the type="inclusive" ever means anything at all (but maybe I'm way off base on this one).  Worse yet, possibly, trying to classify "nothing as something" could be a significant contributing factor in what makes something like EAD so hard to implement for smaller repositories.

I think that these issues were also confusing to me since <unitdate> types can only have a value of "bulk" or "inclusive" (and, like Kris mentions, "single" used to be permitted, but is now deprecated), whereas <date> types can have any value whatsoever:

		<xs:attribute name="type">
				<xs:restriction base="xs:token">
					<xs:enumeration value="bulk"/>
					<xs:enumeration value="inclusive"/>


		<xs:attribute name="type"/>

I get the differences between those tags now (permitting you to tag something, for instance, as <date type="copyright">), but when I first started working with EAD I would see things like <date type="single">.  And that really made me pause, since I would then think, "well, why isn't that type valid for unitdates?"

As long as encoders are following ISO-8601, I think that that would be the most useful practice for both unitdates and dates (that, and whether unitdates are marked as "bulk" or not...  though I still don't know of any systems utilizing bulk dates in any way, aside from display).


-----Original Message-----
From: Encoded Archival Description List [mailto:[log in to unmask]] On Behalf Of Mark Carlson
Sent: Thursday, July 29, 2010 1:03 PM
To: [log in to unmask]
Subject: Re: Question about unitdate type attribute

Based on my personal experience, I would caution people against using 
the "nothing means something" technique of encoding as a general 
practice.  Sometimes the lack of something doesn't always mean what you 
think.  Lack of something can also mean that you just forgot to put that 
"something" in.  If you really need to distinguish single dates from 
non-single dates, I would recommend that you use another technique that 
is more robust such as using one of the other attributes.  If you 
normalize dates, you can determine a single date by the value in the 
normal attribute.

Mark Carlson
Special Collections
University of Washington Libraries

On 7/28/2010 10:36 AM, Custer, Mark wrote:
> Michele,
> I remember being confused about this when starting to look at collection dates in our EAD records.  For our personal best practices, I opted for this:
> Include type="bulk" when necessary
> Include type="inclusive" when a date range
> Exclude the type attribute altogether if a single date
> That way, I figured that I could easily isolate all three instances if need be.
> Mark Custer
> -----Original Message-----
> From: Encoded Archival Description List [mailto:[log in to unmask]] On Behalf Of Kris Kiesling
> Sent: Wednesday, July 28, 2010 12:18 PM
> To: [log in to unmask]
> Subject: Re: Question about unitdate type attribute
> The type attribute value "single" was valid in EAD Version 1.0,
> but was deprecated in Version 2002 (I don't recall why at this
> point), so is no longer a valid value for<unitdate type="">.
> Kris
> Kris Kiesling
> Elmer L. Andersen Director of Archives and Special Collections and
> Assistant University Librarian for Special Collections Advancement
> 305 Andersen Library
> 222 21st Ave. S.
> University of Minnesota
> Minneapolis, MN  55455
> voice:  612-626-5776
> fax:  612-625-5525
> -----Original Message-----
> From: Encoded Archival Description List
> [mailto:[log in to unmask]] On Behalf Of Michele R Combs
> Sent: Wednesday, July 28, 2010 10:49 AM
> To: [log in to unmask]
> Subject: Question about unitdate type attribute
> For unitdate, the RLG best practices document mentions three
> kinds: bulk, inclusive, and single.  (See page 14 here
> ).
> However, the EAD Tag Library only mentions bulk and inclusive (see
> ).
> Is 'single' in fact a legitimate option for the 'type' attribute?
> Since the RLG BP also says the type attribute is mandatory, we've
> just been using type=inclusive for all dates regardless, but now
> that I've noticed this in the RLG doc, it's made me wonder.
> Michele
> (be green - don't print this email!)
> ~~~~~~~~~~~~~~~~~~
> Michele Combs
> Manuscripts Librarian
> Special Collections Research Center
> Syracuse University Libraries
> 222 Waverly Ave.
> Syracuse, NY  13244
> 315-443-2081
> [log in to unmask]
> ~~~~~~~~~~~~~~~~~~