Hi Mike, and List,

> In order to support multi-part access terms, <controlaccess> elements (persname, corpname, famname, name, subject, geogname, function, occupation, and title) will now require one or more <part> elements.

This seems like a good development. We (Archives Hub) already break down names in this way - we kind of implemented a hack way back because EAD didn't' allow this but we always felt it was a good idea. (slightly smug there….). 

You seem to be saying that <part> will be required. 

I note that in EAC-CPF you can have

<part>Brown, Bob</part>

So, the parts in this case are all in one 'part'.  There is no idea here of trying to get a name string separated out into parts in current EAD descriptions? I'm curious because we're trying to do that with EAD that we get in from other systems, and its not easy to do, so it would be really useful to find out if others have done it.  We've managed it reasonably well with the more standard names, but things like Kings and Queens and Dukes and Baronesses and compound surnames are harder to work with.  

I also note the example:

<nameEntry>
<part localType="surname">Lemoyne</part>
<part localType="forename">Francois</part>
…
</nameEntry>

We could convert our tags to use <part>, but I'm wondering if there has been any discussion around the use of localType values? For Linked Data work - and other aggregation work I guess -  it would be great if we had a consensus around 'surname', 'forename', 'dates', 'title' etc - a consensus as to what they mean. It might help with future 'same as' work. 

We separate the parts out in our Linked Data, e.g. http://data.archiveshub.ac.uk/page/person/ncarules/skinnerbeverley1938-1999artist - you can see the view shows the parts of the name as separate triples.  If another archive used the same values it would potentially make it easier to hook into the data. 

Just a few thoughts really…as you said you encouraged discussion :-)

cheers,
Jane

Jane Stevenson
The Archives Hub
Mimas, The University of Manchester
Devonshire House, Oxford Road
Manchester M13 9QH

email:[log in to unmask]
tel: 0161 275 6055
website: archiveshub.ac.uk
blog: archiveshub.ac.uk/blog
twitter: twitter.com/archiveshub




On 3 Sep 2013, at 04:38, Michael Rush <[log in to unmask]> wrote:

> All,
> 
> This is the third in a series of emails in which I will highlight upcoming changes to EAD.  As I previously wrote, I hope this stimulates discussion and comment, and serves as inspiration for the EAD community to engage with the beta release of EAD3.  More information on the revision and the beta comment form are available at http://www2.archivists.org/groups/technical-subcommittee-on-encoded-archival-description-ead/ead-revision-comments.  
> 
> Updating Access Terms
> 
> In order to support multi-part access terms, <controlaccess> elements (persname, corpname, famname, name, subject, geogname, function, occupation, and title) will now require one or more <part> elements.  For example, it will now be possible to encode the equivalent of MARC subfields.  
> 
> Support Multi-Language Finding Aids
> 
> In order to better support the encoding of finding aids containing multiple languages and scripts, we have added language code and script code attributes (@lang and @script) to all non-empty EAD elements.  We are also in the midst of a review to make sure all appropriate elements can repeat to support multi-language description.
> 
> Align with XHTML
> 
> Where feasible, we have made modest changes to more closely align display elements with XHTML.  Those changes include the following:
> 	• Minor tweaks to <table>
> 	• Minor tweaks to <list>
> 	• Remove <blockquote>, <table>, and <chronlist> from within <p>
> 	• Limit <blockquote> to a block element, add <quote> for inline use.
> Fix <note> Craziness
> 
> There are 8 semantically distinct uses of <note> in EAD 2002.  In order to bring some clarity to the situation, the <note> element itself has been replaced by context-appropriate note elements including <didnote> (in the <did>), <footnote> (in mixed content contexts), <controlnote> (in <notestmt>), and <descriptivenote> (in various structured elements - more on those later).  We will also improve documentation of when to use the <odd> element as an alternative to <note>.
> 
> As always, questions and comments are greatly appreciated.
> 
> Best,
> 
> Mike Rush
> TS-EAD co-chair