EAD Normalization Group best practices for optimizing EAD ingest to ArchivesSpace

Reading order	Element category	Practice	Reason	Reason category	Next step
1	Schema	Use the canonical EAD schema, not the Harvard modified schema	AS expects data that conforms to the canonical schema.	Schema	Write documentation
2	<frontmatter>	No frontmatter	This will be added by EAD export from AS	Former practice no longer needed
3	<language>				Best practice needs to be identified
4	<descgrp>	No descgrp	This will not load to AS	Practice not supported by AS EAD ingest
	<arrangement>	Do not embed <arrangement> within <scopecontent>	Roundtripped EAD from AS will be invalid	Practice not supported by AS EAD export
	<c>	Always include an @level attribute value on all <c>s. If using @level="otherlevel" always include an @otherlevel value.	<c> without a @level will ingest as "otherlevel" but lack @otherlevel value	New attribute data required	Documentation needed
	<c>	All components should have <unittitle>; in cases where formerly archivsts might have used only <unitdate>, the parent <c>'s unittitle is often a good choice	The component-centered display in ArchivesSpace makes any component lacking a the context provided by <unittitle> text vague and cryptic, hampering recognition and interpretation of the component.	New content strongly recommended
	<c>	All components must have either a <unitdate> or a <unittitle>	EAD lacking this data will not load to AS	New content required
	<chronlist>	<chronlist> should stand alone, not be embedded within <bioghist>	Will load twice into AS	Practice not supported by AS EAD ingest
	<container>	<container> must include type and label attributes, cannot describe multiple containers in one container element, and should not include type of container as part of content.	AS accommodates container numbers and types, but does not accommodate note-like container information. In addition, AS creates "top container" records based on EAD ingest. These are linked records. Placing a range of boxes, for example, in a single container element creates incorrect data about containers.	Data model in AS is different from EAD	Documentation needed
	<controlaccess>	No <title> in <controlaccess>	Finding aid will load, but data will be lost. Use <subject> or other appropriate element	Practice not supported by AS EAD ingest
	<corpname>	@role ???			Best practice needs to be identified
	<creation>	<creation> statement should include ingest information	Include ingest to AS in your creation statement, e.g. "Created in Oxygen on 2016-11-18; ingested to AS on 2016-12-12"	New content required	Needs to be tested
	<dao>	One Digital Object per Archival Object	Automated linking to objects in the DRS is based on the ref_id of the Archival Object, which is used as an owner supplied name in DRS.	New limit
	<dao>	Supply a title for digital archival objects; use <unittitle> of parent <c>	xlink@title attribute is required by AS ingest	New attribute data required
	<dao>	<daodesc>???			Identify best practice
	<dao>	To achieve thumbnails, <daogrp> must be coded thus: ????			Identify best practice
	<extent>	Collection-level <physdesc><extent> is required	EAD lacking this data will not load to AS	New content required
	<extent>	No mixed content within <physdesc>	Finding aid will ingest, but content will be lost. Specifically, if a <physdesc> has some child elements, any text that is not inside a child element will be left behind during ingest. An entirely plain-text <physdesc> is OK.	New limit	Documentation needed
	<extent>	<extent> must begin with a number	EAD with non-numerical extent will not load to AS	New limit	Documentation needed
	<extref>	<extref> should be used more sparingly, consider using only if @href values link Harvard-managed links	Link rot (has nothing to do with AS), except that during migration, links became noticable and rot was there	New recommendation
	<index>	No nested indexes	Import may succeed, but data will be lacking from AS	Practice not supported by AS EAD ingest
	<index>	Instead of creating <index>es, add controlaccess terms to components	This allows search and retrieval of all components across the whole corpus rather than in one finding aid.	Better data model for discovery and retrieval
	<indexentry>	No nested indexentries	Import may succeed, but data will be lacking from AS	Practice not supported by AS EAD ingest
	<list>	No nested lists	Import may succeed, but data will be lacking from AS	Practice not supported by AS EAD ingest
	<list>	no <defitem> or <list type="deflist">	Import may succeed, but data will be lacking from AS	Practice not supported by AS EAD ingest
	<name>	Avoid <name>	Import may succeed, but data will be lacking from AS, use a more specific <persname>, <corpname>, or <geogname>	Practice not supported by AS EAD ingest
	<namegrp>	No namegrps	Import may succeed, but data will be lacking from AS	Practice not supported by AS EAD ingest
	<note>	Do not use <note> anywhere; where legal, use <odd> preferably with <head>	Import may succeed, but <note> will be lacking from AS; <head> in <odd> provides a better label than "generic note"	New limit
	<origination>	No mixed content; child elements required	Import may succeed, but data will be lacking from AS. Any content not within the child elements <corpname>, <famname>, or <persname> will not go into AS. It will not stop ingest, but data will be lost. Attribute values will also be lost.	Practice not supported by AS EAD ingest; new constraint
	<persname>	@role ???			Best practice needs to be identified
	<processinfo>	Finding aid must have a <processinfo> with <head>Aleph ID</head> and content containing the Aleph record number for the collection	Indexing of finding aids in Primo and connecting them with bibliographic records depends on this exact specification being carried out successfully.	New content required	Documentation needed
	<ref>	<ref>????			Best practice needs to be identified
	<table>	Do not use <table>	Longstanding practice to be continued	Existing limit
	<unitdate>	Supply value for @normal in <unitdate>	This had formerly been accomplished through OASIS loader	New attribute data required
	<unitdate>	Supply certainty="approximate" value for dates if approximate		New attribute data required
	<unitdate>	Do not use @startYear @endYear	These are harvard-specific attributes and will get lost in AS ingest	New limit
	<unitdate>	Do not nest <unitdate> within <unittitle>	These are un-nested during AS ingest. Starting with nested <unitdate>s in EAD will give archivists an unrealistic idea of what the description will convey when un-nested.	New limit
	<unitdate>	Use separate <unitdate> elements for bulk and inclusive dates, and indicate these differences by setting the @type attribute accordingly	AS cannot ingest two dates from one <unitdate> tag.	New limit
	<unitdate>	Indicate approximation in <unitdate>s by setting the attribute @certainty="approximate"	Circa or approximate as part of the date expression are not machine-actionable	New recommendation
	<unitdate>	If there are no dates, do not use <unitdate> at all	Older practice often resulted in the following, which cannot be ingested by AS <unitdate>undated</unitdate>. Consider whether "undated" belongs as part of the title.	New limit
	<unitid>	Collection-level <unitid> is required	EAD lacking this data will not load to AS	New content required
	<unitid>	Use only one <unitid>. If more than one <unitid> is needed, either place them in separate <c> elements or concatenate all into a single <unitid>	AS will ingest the finding aid, but content will be lost. All but one of the <unitid>s will be lacking.	New limit
	<unittitle>	Collection-level <unittitle> is required	EAD lacking this data will not load to AS	New content required
	<unittitle>	Use only one <unittitle>. If more than one <unittitle> is needed, either place them in separate <c> elements or concatenate all into a single <unittitle>	AS will ingest the finding aid, but content will be lost. All but one of the <unittitle>s will be lacking.	New limit
	<extent>	All <extent> measurement types must come from same list used in AS; if non-canonical measurements are needed, consider a separate <physdesc>	Non-matches will have two results: calculations based on measurements will be inaccurrate, AS extent drop-down will become cluttered	New limit	Documentation needed
	<bibliography>	Avoid <bibliography>?			Best practice needs to be identified
	<ptrgrp>	avoid <ptrgrp>???			Best practice needs to be identified