{"id":2218,"date":"2020-09-17T18:18:42","date_gmt":"2020-09-17T18:18:42","guid":{"rendered":"https:\/\/archives-library.wcsu.edu\/cao\/?page_id=2218"},"modified":"2025-10-03T15:04:41","modified_gmt":"2025-10-03T15:04:41","slug":"new-coding-conventions","status":"publish","type":"page","link":"https:\/\/archives-library.wcsu.edu\/cao\/new-coding-conventions\/","title":{"rendered":"Coding Conventions"},"content":{"rendered":"
\n\n

CAO has a few simple required coding conventions for the EAD finding aids that it searches.\u00a0 The requirements below ensure that CAO functions as intended. None of these coding conventions run contrary to best practices for DA:CS or EAD. EADs that are indexed in CAO must<\/strong> be “well-formed<\/a>” and valid (either against the 2002 schema or the v.1 DTD* – soon, we anticipate that CAO will be able to accommodate EAD3).\u00a0<\/p>\n

In general, your EADs should be clean of unnecessary spaces and line breaks, especially within tags. This is not an issue if you are using a tool like ArchivesSpace to generate your EAD. If you are encoding by hand with a text editor, validate it.\u00a0<\/p>\n

If you are using a tool like ArchivesSpace, AtoM, Archivists’ Toolkit, Archon, etc. to generate EAD, many of the coding conventions are enforced by the software.***<\/p>\n

1. Your finding aid must have a creator, title, abstract, biographical\/historical note<\/b>\u00a0and a scope\/content note<\/b>:<\/span><\/p>\n

A finding aid\/collection must have a creator. <\/strong>If you use ArchivesSpace, this would be fulfilled with an agent with role as creator.<\/p>\n

In EAD, something like this:<\/p>\n

<origination<\/span> label<\/span>=”Creator<\/a>“> <\/span> <persname<\/span> rules<\/span>=”dacs<\/a>” source<\/span>=”ulan<\/a>“>Hudiakoff, Andrei, 1894-1985<\/persname<\/span>> <\/span> <\/origination<\/span>><\/p>\n

A finding aid\/collection must have a title. <\/strong><\/p>\n

<archdesc<\/span> level<\/span>=\"collection<\/a>\">\n<\/span>    <did<\/span>>\n<\/span>      <repository<\/span>>\n<\/span>        <corpname<\/span>>Western Connecticut State University Archives and Special Collections<\/corpname<\/span>>\n<\/span>      <\/repository<\/span>>\n<\/span>      <unittitle<\/span>>Andrei Hudiakoff Published Illustrations<\/unittitle<\/span>>\n<\/span>      <origination<\/span> label<\/span>=\"Creator<\/a>\">\n<\/span>        <persname<\/span> rules<\/span>=\"dacs<\/a>\" source<\/span>=\"ulan<\/a>\">Hudiakoff, Andrei, 1894-1985<\/persname<\/span>>\n<\/span>      <\/origination<\/span>>\n<\/span>      <unitid<\/span>>MS 066<\/unitid<\/span>>

Then make sure you have an <abstract>, <scopecontent> <\/strong>and <bioghist><\/strong>.<\/pre>\n
2. Have a unique eadid:<\/strong><\/span><\/p>\n
<eadid<\/span> countrycode<\/span>=\"US<\/a>\" mainagencycode<\/span>=\"US-ctdabn<\/a>\">ctdbn_ms066_hudiakoff<\/eadid<\/span>>.<\/pre>\n
Your filename should be the same as your eadid (though, the eadid should not have a file extension)<\/b>.\u00a0 In the example for the eadid at the top of this section, the filename of that EAD should be: ctdbn_ms066_hudiakoff.xml.\u00a0 Also, keep in mind that as you are sharing your data in this database with other repositories using ids and filenames, your filename\/id should attempt to be unique<\/strong>.\u00a0 If it is not, another repository’s finding aid with the same name may replace yours in the database. If this does happen, no worries.\u00a0 We’ll work with you to rename the EAD.\u00a0 If your file has no eadid, it will be rejected<\/strong> from the indexer.**\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0<\/p>\n
Filenames<\/strong> and <eadid>s should<\/strong> be primarily alphanumeric – underscores are OK.\u00a0 You should not<\/strong> use spaces, hyphens, quotation marks, question marks, plus signs, periods\u00a0 – except before the file extension- <\/em>, ampersands, etc.\u00a0 Clean filenames\/ids (for example “rg045_rogers”, “mss0003_42”, “WillingtonUpton”, etc.) help in reducing errors that can occur in the software when file names look like a coding syntax.\u00a0\u00a0<\/p>\n
3. It MUST NOT have a normal attribute in a <unitdate> with a start date greater than the end date in a date range<\/strong>\u00a0<\/span>(or a date range greater than 2000 years):<\/strong><\/span> This will cause your file to be rejected by the indexer.\u00a0 A finding aid that contains something like this: <unitdate normal=”1890\/1871″>1890-1871<\/unitdate> or <unitdate normal=”10\/2023″>10-2023<\/unitdate> will not be indexed.<\/p>\n
4.\u00a0 At least one level declared for in the inventory and a title and\/or date for each component:<\/b><\/span><\/span><\/p>\n
    \n
  • The inventory must<\/strong> have at least a level designation on your first <c>, like <c01 level=”series”>, for example (ASpace forces you to set a level);\u00a0<\/li>\n
  • you should either have a title or a date for a component.\u00a0 If you do not, the system will add “untitled” to your component.<\/li>\n
  • we have noted a number of repositories using <unitid>s as titles of series or subseries.\u00a0 On testing and rollout, we altered a number of finding aids with this issue and changed their <unitid>s to <unittitle>s, but will only do this for the CAO rollout.<\/li>\n<\/ul>\n
    \n
    That’s it.\u00a0 If you’re worried that this is a lot of work, you shouldn’t – again, these conventions above are all in line with EAD and DA:CS best practice.\u00a0<\/p>\n
    ——————————————<\/p>\n<\/div>\n
    For CAO ArchivesSpace <\/span><\/strong>users<\/strong><\/span>: if you are using CAO to harvest your ASpace\u00a0 data, every resource must be public<\/strong>, have an agent with the role set to creator<\/strong>, and include these notes: an abstract,<\/strong> a biographical historical, <\/strong>and a scope and contents<\/strong> or the resource will not be exported. And ASpace users need to include an eadid<\/strong> just like everyone else – see the note above!\u00a0 We name your file the same as the eadid.
    <\/em><\/p>\n
    FOR ASPACE harvests:<\/strong> If your files are being harvested from an ArchivesSpace instance and there is no eadid for a resource, we will generate one based on your repository code and the ASpace resource number and then save and name the EAD file with that eadid value; for example: ctrepoid_noEADID_3_45 would be the eadid for the EAD file, ctrepoid_noEADID_3_45.xml.\u00a0 Where ctrepoid=your repository’s id, 3=your repository number in the ASpace instance, and 45=the resource number in the ASpace instance.\u00a0 In viewing your files, you see a filename with noEADID, you can figure out which of your ASpace resources don’t have the eadid by the filename CAO’s EAD has been assigned.<\/em><\/p>\n\n\n
    * we’ve found a few anomalies with EAD v.1 – if you are still using it, you should probably update your encoding to EAD2002.<\/em><\/p>\n\n\n\n
    ** If for some reason your file with no eadid gets indexed, it will cause all your repository’s files to fail.  We will have to delete that null eadid file from the database.<\/em> <\/p>\n\n\n\n
    *** it has come to our attention that in-line invalid XML tagging within ArchivesSpace fields is permitted and will not prevent the EAD export.  The implication is that ASpace may export invalid XML.  Invalid XML can’t be indexed by CAO.  If you use in-line tagging, try to export a pdf version of the finding aid.  If ASpace throws an error, you have invalid tagging somewhere. <\/p>\n\n\n<\/div>","protected":false},"excerpt":{"rendered":"
    CAO has a few simple required coding conventions for the EAD finding aids that it searches.\u00a0 The requirements below ensure that CAO functions as intended. None of these coding conventions run contrary to best practices for DA:CS or EAD. EADs that are indexed in CAO must be “well-formed” and valid (either against the 2002 schema …<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":{"0":"post-2218","1":"page","2":"type-page","3":"status-publish","5":"category-technical-information"},"_links":{"self":[{"href":"https:\/\/archives-library.wcsu.edu\/cao\/wp-json\/wp\/v2\/pages\/2218","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/archives-library.wcsu.edu\/cao\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/archives-library.wcsu.edu\/cao\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/archives-library.wcsu.edu\/cao\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/archives-library.wcsu.edu\/cao\/wp-json\/wp\/v2\/comments?post=2218"}],"version-history":[{"count":0,"href":"https:\/\/archives-library.wcsu.edu\/cao\/wp-json\/wp\/v2\/pages\/2218\/revisions"}],"wp:attachment":[{"href":"https:\/\/archives-library.wcsu.edu\/cao\/wp-json\/wp\/v2\/media?parent=2218"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/archives-library.wcsu.edu\/cao\/wp-json\/wp\/v2\/categories?post=2218"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/archives-library.wcsu.edu\/cao\/wp-json\/wp\/v2\/tags?post=2218"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}