Difference between revisions of "EAD3 implementation guideline"

From Archives Portal Europe Wiki
Jump to: navigation, search
(Info on EAD3 and the sample files used)
(Info on EAD3 and the sample files used)
Line 27: Line 27:
 
Since opening up Notary records via AFA's can be done via two different approaches: either copying the information from an index on Notary records (in Dutch "Repertorium") to an AFA or copying the information of all full Notary record to an AFA (but in both approaches including links to the scans of the full Notary records), we will provide a guideline for these two methods here and will provide sample files for both methods; for the first approach in two versions: a minimal and a maximal tagged one, so an AFA with only mandatory EAD3 elements and an AFA with all recommended EAD3 elements, and for the second approach only a maximal tagged one, because this one is aimed at describing full Notary records in detail anyway:
 
Since opening up Notary records via AFA's can be done via two different approaches: either copying the information from an index on Notary records (in Dutch "Repertorium") to an AFA or copying the information of all full Notary record to an AFA (but in both approaches including links to the scans of the full Notary records), we will provide a guideline for these two methods here and will provide sample files for both methods; for the first approach in two versions: a minimal and a maximal tagged one, so an AFA with only mandatory EAD3 elements and an AFA with all recommended EAD3 elements, and for the second approach only a maximal tagged one, because this one is aimed at describing full Notary records in detail anyway:
 
* the original FA '''NL-TbRAT-115''' can be downloaded in EAD2002/XML [http://www.archivesportaleuropefoundation.eu/images/docs/NL-TbRAT-115.xml here] (and here as [http://www.archivesportaleuropefoundation.eu/images/docs/NL-TbRAT-115.zip zipfile])
 
* the original FA '''NL-TbRAT-115''' can be downloaded in EAD2002/XML [http://www.archivesportaleuropefoundation.eu/images/docs/NL-TbRAT-115.xml here] (and here as [http://www.archivesportaleuropefoundation.eu/images/docs/NL-TbRAT-115.zip zipfile])
* the sample AFA for '''NL-TbRAT-115_916''' can be downloaded in the EAD3/XML minimal version [http://www.archivesportaleuropefoundation.eu/images/docs/NL-TbRAT-115_916_minimal.xml here] (and here as [http://www.archivesportaleuropefoundation.eu/images/docs/NL-TbRAT-115_916_minimal.zip zipfile]) and in the maximal version [http://www.archivesportaleuropefoundation.eu/images/docs/NL-TbRAT-115_916_normal.xml here] (and here as [http://www.archivesportaleuropefoundation.eu/images/docs/NL-TbRAT-115_916_normal.zip zipfile])
+
* the sample AFA for '''NL-TbRAT-115_916''' can be downloaded in the EAD3/XML minimal version [http://www.archivesportaleuropefoundation.eu/images/docs/NL-TbRAT-115_916_minimal.xml here] (and here as [http://www.archivesportaleuropefoundation.eu/images/docs/NL-TbRAT-115_916_minimal.zip zipfile]) and in the maximal version [http://www.archivesportaleuropefoundation.eu/images/docs/NL-TbRAT-115_916_maximal.xml here] (and here as [http://www.archivesportaleuropefoundation.eu/images/docs/NL-TbRAT-115_916_maximal.zip zipfile])
* the sample AFA for '''NL-TbRAT-115_871''' can be downloaded in the EAD3/XML maximal version [http://www.archivesportaleuropefoundation.eu/images/docs/NL-TbRAT-115_871_normal.xml here] (and here as [http://www.archivesportaleuropefoundation.eu/images/docs/NL-TbRAT-115_871_normal.zip zipfile])
+
* the sample AFA for '''NL-TbRAT-115_871''' can be downloaded in the EAD3/XML maximal version [http://www.archivesportaleuropefoundation.eu/images/docs/NL-TbRAT-115_871_maximal.xml here] (and here as [http://www.archivesportaleuropefoundation.eu/images/docs/NL-TbRAT-115_871_maximal.zip zipfile])
  
 
In order to present you the full use cases, the scans of the material described in those sample files can be downloaded here:
 
In order to present you the full use cases, the scans of the material described in those sample files can be downloaded here:

Revision as of 13:50, 16 October 2016

The Archives Portal Europe team has decided to start working on enabling the ingestion of finding aids in the new EAD3 format in the portal. As a result of the cooperation between the Archives Portal Europe Foundation (APEF) and the Dutch project Digitale Taken Rijk (DTR), it will start this endeavour by enabling the ingestion of so called "additional finding aids" in EAD3 first.

The DTR-project – launched and funded by the Dutch Ministry of Education, Culture and Science – has to build a digital infrastructure and service organisation for the Dutch National Archives (Nationaal Archief) and eleven Dutch Regional Historical Centers (RHC’s, i.e. former State Archives in the Dutch provinces) and is going to re-use the Archives Portal Europe as an aggregator for finding aids. In addition to this, the DTR-project has asked APEF to also enable the ingestion of additional finding aids and to publish the information of these additional finding aids as 'open data' via its API together with the finding aids information.

But what are additional finding aids exactly and why use EAD3 for them? Well, most of the time the descriptive units of a finding aid describe the archival material only in a general way, although there is a wealth of information available in it, f.i. on events, persons, places, subjects, etc.. Often this information is available, but in a variety of formats: handwritten lists or indexes, card systems, different word processor, spreadsheet or database formats, etc., either made when the material was created or later on by archivists, researchers and/or volunteers. All this information can be called "additional finding aid information". The variety of this information and the variety of the ways in which it's stored, makes it hard to determine a metadata format for it. However, it's worthwhile to explore possibilities for publishing this detailed information in a generic way, because it's important information for researchers.

The Archives Portal Europe team came up with the idea to use EAD/XML for additional finding aids, after all it is "finding aid" information and in principle this information could be stored in the EAD/XML finding aids, f.i. as an index within a descriptive unit. But that will result in huge EAD/XML files, which will probably generate performance problems when handling them, so it's better to create separate additional finding aids and link to them from within the descriptive unit of a finding aid they contain more information on.

Furthermore the Archives Portal Europe team decided to go for EAD3 as the format for the additional finding aids, because – like EAD2002/apeEAD – it's both structured and flexible, but – compared to EAD2002/apeEAD – it also enables tagging metadata in much more detail, so in a more meaningful way, f.i. it enables splitting up information on persons in parts. So this makes EAD3 suitable for tagging all sorts of additional finding aids, not only the ones on Notary records, but also any other additional finding aid describing events, persons, places and subjects in detail, such as birth, marriage and death records, records of courts of law, etc.

The Archives Portal Europe team has also decided not to come up with a subset of EAD3 - like apeEAD is a subset of EAD2002 - but to allow in principle all possibilities of the new EAD3 format, in order to avoid time consuming change request processes later on when content providers will start offering their EAD3 implementations. The team is confident that differences in EAD3 implementations then can be taken care of by a conversion stylesheet which is mainly aimed at harmonising data internally in order to offer them as consistent as possible to end-users via the portal's display and that spreading a general implementation guideline in an early stage of the EAD3 introduction will avoid too many differences in the use of EAD3 among content providers.

This page is a first attempt to produce such an EAD3 implementation guideline, but since the first phase of enabling the ingestion of EAD3 in the Archives Portal Europe will start with enabling the ingestion of additional finding aids in EAD3, and - as a result of the APEF-DTR cooperation - this has to be narrowed down even further to the ingestion of a particular type of additional finding aids, namely the ones on Notary records, this implementation guideline will mainly focus on how to create these kind of additional finding aids in EAD3. However, that being said, this guideline will try to offer 'tagging building blocks' which can be re-used for describing events, persons, places and subjects in other types of additional finding aids as much as possible. And the same goes for the first parts of this guideline: the first (main) parts of an additional finding aid (from now on shortened to: AFA) can also be re-used, f.i. for tagging a full finding aid (from now on shortened to: FA) in EAD3 and that's why in this guideline often the acronym "(A)FA" will be used, indicating that what follows is applicable for AFA's as well as FA's.


Contents


Info on EAD3 and the sample files used



Throughout this implementation guideline as example will be used FA no. NL-TbRAT-115, Inventaris van de notariële archieven Tilburg, 1577-1935, of the Regional Archives of Tilburg, a city in the south of The Netherlands, and in particular descriptive unit number 916 and 871; descriptive unit number 916 consists of an index on the notary records of notary C.J.M. Heufke, working in Tilburg in the period 1917-1935, and descriptive unit number 871 consists of the full records as described in the index of descriptive unit number 916.

Since opening up Notary records via AFA's can be done via two different approaches: either copying the information from an index on Notary records (in Dutch "Repertorium") to an AFA or copying the information of all full Notary record to an AFA (but in both approaches including links to the scans of the full Notary records), we will provide a guideline for these two methods here and will provide sample files for both methods; for the first approach in two versions: a minimal and a maximal tagged one, so an AFA with only mandatory EAD3 elements and an AFA with all recommended EAD3 elements, and for the second approach only a maximal tagged one, because this one is aimed at describing full Notary records in detail anyway:

  • the original FA NL-TbRAT-115 can be downloaded in EAD2002/XML here (and here as zipfile)
  • the sample AFA for NL-TbRAT-115_916 can be downloaded in the EAD3/XML minimal version here (and here as zipfile) and in the maximal version here (and here as zipfile)
  • the sample AFA for NL-TbRAT-115_871 can be downloaded in the EAD3/XML maximal version here (and here as zipfile)

In order to present you the full use cases, the scans of the material described in those sample files can be downloaded here:

  • for the sample AFA NL-TbRAT-115_916 only one scan of this index ("Repertorium") was used: page 1, listing the first twenty Notary records:



Linking a descriptive unit of a FA to an AFA

The concept of AFA's describing descriptive units of FA's in more detail is shown in the presentation on the APEF-DTR cooperation. The idea is to put a link in the element <otherfindaid/> of the descriptive unit of a FA to the accompanying AFA and this is how to do that in the descriptive unit of the FA (either in EAD2002 or apeEAD): /ead/archdesc/dsc/c/otherfindaid:

<otherfindaid>
	<head>Additional Finding Aid</head>
	<p><extref linktype="simple" href="[identifier of the AFA]" actuate="onrequest" show="new">See Additional Finding Aid 
        [identifier of the AFA]</extref></p>
</otherfindaid>

The "href" has to contain the identifier of the AFA to which has to be linked. It will be good practice to compose this identifier out of the identifier of the FA plus and underscore plus the identifier of the descriptive unit for which the AFA is meant. So for an AFA of descriptive unit no. "916" of an FA with as identifer "NL-TbRAT-115", the identifier for the accompanying AFA will be: "NL-TbRAT-115_916".

For AFA's in EAD2002 this identifier has to be put in: /ead/ead/header/eadid and in: /ead/archdesc/did/unitid, for AFA's in apeEAD at least in: /ead/archdesc/did/unitid and for AFA's in EAD3 in: /ead/control/recordid and in: /ead/archdesc/did/unitid (preferably in both, but at least in the second).

For the FA and the AFA to be linked properly in the Archives Portal Europe the identifier for the AFA has to be exactly the same in the "href" of the link in the FA and in the location(s) for it in the AFA as described above. So for the example as described above, the correct tagging would be:

<otherfindaid>
	<head>Additional Finding Aid</head>
	<p><extref linktype="simple" href="NL-TbRAT-115_916" actuate="onrequest" show="new">See Additional Finding Aid
        NL-TbRAT-115_916</extref></p>
</otherfindaid>

Note: such a <otherfindaid/> tagging in a FA in EAD3 would have to be:

<otherfindaid>
	<head>Additional Finding Aid</head>
	<p><ref href="NL-TbRAT-115_916" actuate="onrequest" show="new">See Additional Finding Aid NL-TbRAT-115_916</ref></p>
</otherfindaid>

So EAD2002's "extref" is deprecated within EAD3 and therefore has to be replaced with a "ref" (see the list of all deprecated and obsolete EAD 1.0 / EAD2002 elements and attributes).


Creating an (A)FA in EAD3

The EAD standard recommends a certain structure for the creation of FA's, according to ISAD(G), the international standard for describing archival material. Since we recommend to use EAD not only for FA's, but also for AFA's, the AFA's will follow this structure too. However, since the general information on the archival fonds or collection to which the descriptive unit the AFA describes belongs to is already available in the FA, the general parts of the AFA can be limited to the mandatory information. Therefore we will focus here on the necessary information for the general parts of an AFA.

Structure of a (A)FA in EAD3

The structure of a FA - and by consequence also an AFA - in EAD3 consists of the following parts:

  • The XML declaration and the indication of the character code the document is using:
<?xml version="1.0" encoding="UTF-8"?>


  • The root element <ead/> with namespace declarations and the location of the EAD3 schema:
<ead xmlns="http://ead3.archivists.org/schema/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://ead3.archivists.org/schema/ http://www.archivesportaleurope.net/Portal/profiles/ead3.xsd">


  • The part /ead/control with information on the (A)FA itself (was previously - in EAD2002/apeEAD - the part: /ead/eadheader) --> see below.


  • The part /ead/archdesc with two main parts:
    • /ead/archdesc/did, containing information on the archival fonds or collection the (A)FA is describing --> see below
    • /ead/archdesc/dsc, containing the actual descriptions of the archival material (the descriptive units) --> see below


Main parts of a (A)FA in EAD3 in more detail

MAIN PART 1: /EAD/CONTROL

The mandatory <control/>-element may have attributes to identify the values of authoratative sources used throughout the (A)FA:

Furthermore the mandatory parts of the /ead/control-part of an (A)FA in EAD3 are:

<control countryencoding="iso3166-1" dateencoding="iso8601" langencoding="iso639-2b" relatedencoding="iso15511" scriptencoding="iso15924">
	<recordid/>
	<filedesc>
		<titlestmt>
			<titleproper/>
		</titlestmt>
	</filedesc>
	<maintenancestatus value=""/>
	<maintenanceagency>
		<agencyname/>
	</maintenanceagency>
	<maintenancehistory>
		<maintenanceevent>
			<eventtype value=""/>
			<eventdatetime/>
			<agenttype value=""/>
			<agent/>
		</maintenanceevent>
	</maintenancehistory>
</control>


Recommended for an AFA as linked from within an FA are these elements:

RECORDID (mandatory)

The value for this element has to be the identifier of the AFA, preferably consisting of the identifier of the original FA it belongs to plus an underscore and the identifier of the descriptive unit it describes in detail. So, when creating an AFA for descriptive unit number 916 of FA NL-TbRAT-115, the identifier (ie recordid) of the AFA for this particular descriptive unit should ideally be: NL-TbRAT-115_916.

Example:

<recordid>NL-TbRAT-115_916</recordid>


FILEDESC (mandatory)

This element is mandatory, is meant to contain all bibliographical information of the (A)FA, contains no value itself, but has to contain at least one element that is mandatory too: <titlestmt/>.

FILEDESC/TITLESTMT (mandatory)

This element is mandatory, contains no value itself, but has to contain at least one element that is mandatory too: <titleproper/> and next to that two other optional elements might be useful for an AFA: <subtitle/> and <author/>.

  • <titleproper/>, mandatory, the value for this element has to be the title of the AFA, preferably consisting of the standard text "Additional Finding Aid for" (or: in Dutch: "Nadere toegang op" plus the value of the <titleproper/> of the original FA it belongs to plus the text "identifier" (or: in Dutch: "inventarisnummer") and then the identifier of the descriptive unit it describes in detail; so, when creating an AFA for descriptive unit number 916 of FA NL-TbRAT-115, the title (ie <titleproper/>) of the AFA for this particular descriptive unit should ideally be: "Nadere toegang op Inventaris van de notariële archieven Tilburg, 1577-1935, inventarisnummer 916".
  • <subtitle/>, optional, in this element a subtitle can be added, which might contain a concatenation of the <unittitle/> of the descriptive unit, preceded by the ones of the higher levels; so, in the case of the AFA NL-TbRAT-115_916 the value for this element would be: "C.J.M. HEUFKE, 1917-1935, Repertoires, 1917".
  • <author/>, optional, in this element an author can be added, which might contain the name of the author responsible for creating the AFA.

Example:

<titlestmt>
	<titleproper>Nadere toegang op Inventaris van de notariële archieven Tilburg, 1577-1935, inventarisnummer 916</titleproper>
	<subtitle>C.J.M. HEUFKE, 1917-1935, Repertoires, 1917</subtitle>
	<author>Wim van Dongen</author>
</titlestmt>⌂


FILEDESC/PUBLICATIONSTMT (optional)

This element is optional, contains no value itself, but has to contain at least one element that is mandatory too: <publisher/> and next to that two other optional elements might be useful for an AFA: <date/> and <address/>. The purpose of this element is to provide information on the publisher of the AFA, most of the time this will be the archival institution that created the AFA and has published it on its website and/or on the Archives Portal Europe.

  • <publisher/>, mandatory, the value of this element has to be the name of the publisher, in most cases the name of the archival institution that publishes the AFA;
  • <date/>, optional, the value of this element has to be the date on which the AFA was published for the first time; this date can be normalised using the attributes @calendar, @era and @normal;
  • <address/>, optional, the value of this element has to be the address of the publisher of the AFA, in most cases the address of the archival institution that publishes the AFA; this information has to be added in the sub-element <addressline/> and this sub-element can be repeated, f.i. one for the name of the street, one for the name of the place and one for the name of the country, etc.

Example:

<publicationstmt>
	<publisher>Regionaal Archief Tilburg</publisher>
	<date calendar="gregorian" era="ce" normal="20160920">20 september 2016</date>
	<address>
		<addressline>Kazernehof 75</addressline>
		<addressline>5017 EV Tilburg</addressline>
		<addressline>Nederland</addressline>
	</address>
</publicationstmt>


FILEDESC/NOTESTMT (optional)

This is an optional element via which the publisher of the AFA, most of the time the archival institution that created the AFA and has published it on its website and/or on the Archives Portal Europe, can add a notification, f.i. on the license under which the AFA is published, this element will always need the sub-elements <controlnote/> and <p/>:

Example:

<notestmt>
	<controlnote>
		<p>This Additonal Finding Aid is published under <ref show="new" actuate="onrequest" 
                 href="http://creativecommons.org/publicdomain/zero/1.0/">CC0 license.</ref></p>
	</controlnote>
</notestmt>


MAINTENANCESTATUS (mandatory)

This mandatory element has to show the status of the AFA. It has a mandatory attribute "value" which has to be filled with "new" or "revised"; it doesn't require any other attribute, nor sub-elements.

Example:

<maintenancestatus value="new"/>


MAINTENANCEAGENCY (mandatory)

This mandatory element has to show the name of the "agency" or (archival) institution that is responsible for maintaining the AFA. It's recommended - not mandatory - to use the attribute @countrycode for it, containing the code for the country the agency is located in, according to ISO 3166-1; furthermore it's also recommended to not only use the mandatory sub-element <agencyname/>, which has to contain the name of the institution, but to also use <agencycode/>, which has to contain the identifier for the institution, preferably as an ISIL-code.

Example:

<maintenanceagency countrycode=NL">
	<agencycode>NL-TbRAT</agencycode>
	<agencyname>Regionaal Archief Tilburg</agencyname>
</maintenanceagency>


LANGUAGEDECLARATION (optional)

The this element is optional, but using it is highly recommended, because it can be used to indicate in which language the AFA is written, which is important in a multilingual environment such as the Archives Portal Europe; it should contain a sub-element <language/> with a mandatory attribute @langcode which has to contain the code for the language used according to ISO 639-2b, and a sub-element <script/> with a mandatory attribute @scriptcode, which has to contain the code for the character set according to ISO 15924. Although not mandatory, the value of the @langcode and @scriptcode could be stated as value for the respective sub-elements <language/> and <script/>, but they might also be explained in an optional sub-element <descriptivenote/>, using a <p/>-element.

Example:

<languagedeclaration>
	<language langcode="dut">Dutch</language>
	<script scriptcode="Latn">Latin</script>
	<descriptivenote>
		<p>This additional finding aid is written in Dutch.</p>
	</descriptivenote>
</languagedeclaration>


LOCALTYPEDECLARATION (optional for EAD3, but recommended for (A)FA's using this guideline)

Although this element is optional, it is highly recommended for (A)FA's that are to be ingested in the Archives Portal Europe and that will be based on this implementation guideline, because it offers a possibility to declare and specify the conventions (controlled vocabularies) that are recommended in this guideline for the attribute @localtype (as well as the attribute @relator, see below) within various elements of EAD3.

This element should contain the sub-elements <abbr/> and <citation/> to state the acronym for the convention (controlled vocabulary) used and a link to the online presentation of it, including the official name for it. More information on the convention or controlled vocabulary can be put in an optional sub-element <descriptivenote/> using a <p/>-element.

Example:

<localtypedeclaration>
	<abbr>apetypes</abbr>
	<citation href="http://wiki.archivesportaleurope.net/index.php/EAD3_apetypes" linktitle="Archives Portal Europe EAD3 @localtype
        and @relator values" actuate="onload" show="new">Convention for values of EAD3 @localtype and @relator used by the Archives Portal
        Europe</citation>
	<descriptivenote>
		<p>This convention is maintained by the Working Group on Standards (WGoS) of the Archives Portal Europe Foundation (APEF).</p>
	</descriptivenote>
</localtypedeclaration>

Note: when using the attribute @localtype in any EAD3 element/sub-element, it is good practise to use the acronym for the convention or controlled vocabulary in another attribute @rules --> see below.

Note: the first draft of the document "Convention for values of EAD3 @localtype and @relator used by the Archives Portal Europe" can be found here.

MAINTENANCEHISTORY (mandatory)

This mandatory element has to contain all relevant information on the creation of the (A)FA, and on all changes and revisions of the document afterwards. Each of these events have to be documented in a separate sub-element <maintenanceevent/>, which has to have four mandatory sub-elements and can have one optional sub-element:

  • <eventtype/>, mandatory, just containing an attribute @value for describing the nature of the event and which may have one of these values: "cancelled", "created", "deleted", "derived", "revised", "unknown", "updated";
  • <eventdatetime/>, mandatory, indicating the date and time of the event, containing as mandatory attribute @standarddatetime for normalising the date and time according to ISO 8601;
  • <agenttype/>, mandatory, just containing an attribute @value for indicating the type of agent that was responsible for the creation or change and/or revision of the document, which may have one of these values: "human", "machine" or "unknown";
  • <agent/>, mandatory, for registering the name of the agent (the name of a person, institution or system) resposible for the creation or change/revision of the document;
  • <eventdescription/>, optional, in which a description of the event can be put.

Example:

<maintenancehistory>
	<maintenanceevent>
		<eventtype value="created"/>
		<eventdatetime standarddatetime="2016-09-20T14:23:42-05:00">20 september 2016</eventdatetime>
		<agenttype value="human"/>
		<agent>Wim van Dongen</agent>
		<eventdescription>Creation of this Additional Finding Aid</eventdescription>
	</maintenanceevent>
</maintenancehistory>


MAIN PART 2: /EAD/ARCHDESC

In the case of an AFA the element <archdesc/> needs to have the value "file" for the attribute @level and we recommend to also use the attribute @localtype with the value: "afa" to enable the Archives Portal Europe's sytem to recognise this particular document type:

<archdesc level="file" @localtype="afa">

The element <archdesc/> consists of two main parts: <did/> and <dsc/>; the <did/>-part contains general information on the descriptive unit the AFA describes and the <dsc/>-part contains the actual detailed information of the AFA, so the content of the descriptive unit in detail.

MAIN PART 2a: /EAD/ARCHDESC/DID

The mandatory elements of the /ead/archdesc/did-part of an EAD3 FA are: at least one element of this list: abstract, container, dao, daoset, didnote, head, langmaterial, materialspec, origination, physdesc, physdescset, physdesc, physdescstructured, physloc, repository, unitdate, unitdatestructured, unitid, unittitle and of course all their dependencies.

For an AFA the following elements are recommended: abstract, head, langmaterial, origination, repository, unitdate, unitid and unittitle (and of those it would be best to at least use these elements as a minimum set: origination, unitdate, unitid,unittitle):

	<did>
		<head></head>
		<unittitle></unittitle>
		<unitid></unitid>
		<unitdate></unitdate>
		<repository>
			<corpname>
				<part></part>
			</corpname>
		</repository>
		<langmaterial>
			<language></language>
		</langmaterial>
		<origination>
			<corpname>
				<part></part>
			</corpname>
		</origination>
		<abstract></abstract>
	</did>



HEAD (optional for EAD3 and for an AFA)

This optional element can contain a title indicating the content of this part of the (A)FA, f.i.: "General descriptive unit description" or (in Dutch): "Algemene archiefbestanddeel beschrijving".

Example:

<head>General descriptive unit description</head>


UNITTITLE (optional for EAD3, but mandatory for an AFA)

This element has to contain the title of the descriptive unit it describes in more detail, if necessary preceded by the content of the <unittitle/>'s of the higher levels of the descriptive unit in the original FA it belongs too; in the case of the AFA NL-TbRAT-115_916 this would be: "C.J.M. HEUFKE, 1917-1935, Repertoires, 1917." (so in fact the same information as could be used for the element <subtitle/> --> see above).

Example:

<unittitle>C.J.M. HEUFKE, 1917-1935, Repertoires, 1917</unittitle>


UNITID (optional for EAD3, but mandatory for an AFA)

The value for this element has to be the identifier of the (A)FA, preferably consisting of the identifier of the original FA it belongs to plus an underscore and the identifier of the descriptive unit it describes in detail; in the case of the AFA for descriptive unit no. 916 of the FA NL-TbRAT-115 this would be: NL-TbRAT-115_916 (so in fact the same information as used for the element <recordid/> --> see above).

As an option the attribute @identifier can be added to this element, which can contain a link to a persistent identifier, f.i. for pointing the end-user to the presentation of this information on the website of the content provider.

Example:

<unitid identifier="http://proxy.handle.net/013/eb79aebe-4c7d-4282-ab49013">NL-TbRAT-115_916</unitid>

Note: this is an example of a persistent identifier according to the Handle System, but over here it's a fake one.

UNITDATE (optional for EAD3, but mandatory for an AFA)

The value for this element has to be the date of the descriptive unit, so in the case of the AFA NL-TbRAT-115_916 this would be: "1 januari 1917 - 21 mei 1917". The <unitdate/> can contain a few attributes of which only one is mandatory:

  • @calendar, optional, indicating the system used for registering time, this attribute can contain as values: "gregorian" or "julian", most of the time "gregorian" will have to be used;
  • @era, optional, indicating the period of time during which the dates were used, this attribute can contain as values: "ce" (= common era) or "bce" (= before common era), most of the time "ce" will have to be used;
  • @normal, mandatory, containing the standardised form of the date according to the ISO 8601 standard.

Example:

<unitdate calendar="gregorian" era="ce" normal="1917-01-01/1917-05-21">1 januari 1917 - 21 mei 1917</unitdate>

Note: EAD3 allows a more sophisticated date range tagging now, using the element <unitdatestructured/>, having the possibility to use an attribute like @unitdatetype (with as possible values: "bulk" and "inclusive") and the sub-elements <daterange/> and <fromdate/> and <todate/> (which can be normalised using the attribute @standarddate and the ISO 8601 standard); feel free to use it, but for now the Archives Portal Europe will stick to the "legacy" tagging.

Example:

<unitdatestructured unitdatetype="inclusive">
        <daterange>
                <fromdate standarddate="1917-01-01">1 januari 1917</fromdate>
                <todate standarddate="1917-05-21">21 mei 1917</todate>
        </daterange>
</unitdatestructured>


REPOSITORY (optional for EAD3, but mandatory for an AFA)

This element has to contain the name of the archival institution that holds the archival material described in the (A)FA; in the case of the AFA NL-TbRAT-115_916 this is: "Regionaal Archief Tilburg"; this name has to be put in the sub-elements <corpname/> and <part/>.

Example:

<repository>
	<corpname>
		<part>Regionaal Archief Tilburg</part>
	</corpname>
</repository>

Note: of course it's possible to use more than one <part/>-element for repository identification, f.i. to also provide the address and the location of the repository separately.

LANGMATERIAL (optional for EAD3 and for an AFA)

This optional element provides a possibility to describe the language of the archival material in detail. it should contain a sub-element <languageset/> with a mandatory attribute @langcode which has to contain the code for the language used according to ISO 639-2b, and a sub-element <script/> with a mandatory attribute @scriptcode which has to contain the code for the character set according to ISO 15924. Although not mandatory, the value of the @langcode and @scriptcode could be stated as value for the respective sub-elements <language/> and <script/>, but they might also be explained in an optional sub-element <descriptivenote/>, using a <p/>-element.

Example:

<langmaterial>
	<languageset>
		<language langcode="dut">Dutch</language>
		<script scriptcode="Latn">Latin</script>
		<descriptivenote>
			<p>The documents are written in Old Dutch.</p>
		</descriptivenote>
	</languageset>
</langmaterial>

Note: if the archival material contains documents in more than one language, the element-set <languageset/> could be repeated; in that case it would be good practise to state at c-level what documents are in what language, using this same element <langmaterial/>.

ORIGINATION (optional for EAD3, but mandatory for an AFA)

This element has to contain information on the entity (a corporate body, a family or a person) that was responsible for creating the archival material. This element may contain a sub-element to indicate these entities: <corpname/>, <famname/> or <persname/> (and also the more general: <name/>).

These sub-elements may contain attributes which are not mandatory but highly recommended for AFA's; for these entity sub-elements these attributes are recommended: @identifier, @relator and @rules, and for the sub-element <part/> within those entity sub-elements these attributes are recommended: @localtype and @rules:

  • @identifier, optional, the value could be an identifier to an external source or authority file system, describing the same entity, so a uri or url; it could also be the identifier for a file that is already in the Archives Portal Europe, then it will act as an internal reference and in that case just providing the identifier of that other file is enough as value for this attribute (so in that case no uri or url is needed);
  • @localtype, optional, a way to define the value of the element it belongs to in a more semantic way; the values which can be used for @localtype should be defined in a general document to which <localtypedeclaration/> is pointing (see above) and can be applied to a lot of EAD3 elements;
  • @relator, optional, a way to define the role of the entity that is being described; the values which can be used for @relator should be defined in a general document; this can be dealt with within the document for defining the values for @localtype;
  • @rules, optional, pointing to the general document which is used for defining the values of @localtype (and @relator), so the value must be the same as the value of <abbr/> within <localtypedeclaration/>, so: "aperules" (see above).;
  • @lang, optional, indicating the language the values of the elements used are written in according to the ISO 639-2b standard, so for Dutch this will be: @lang="dut".

Example:

<origination>
	<persname identifier="123456" relator="creator" rules="apetypes">
		<part localtype="firstname" rules="apetypes" lang="dut">Christoffel Johan Meindert</part>
		<part localtype="lastname" rules="apetypes" lang="dut">Heufke</part>
		<part localtype="gender" rules="apetypes" lang="dut">man</part>
		<part localtype="residence" rules="apetypes" lang="dut">Tilburg</part>
		<part localtype="role" rules="apetypes" lang="dut">kandidaat notaris</part>
		<part localtype="dates" rules="apetypes" lang="dut">1 januari 1917 - 21 mei 1917</part>
	</persname>
</origination>

Note: the example above shows the use of @identifier as an internal link (for use within the Archives Portal Europe), f.i. in case the Regional Archives of Tilburg also have an EAC-CPF file on Christoffel Johan Meindert Heufke available in the portal (having as identifier "123456", which would be placed in <recordId/> in an EAC-CPF file); if this is not the case and such a file is available somewhere else, then the value of @identifier would have to contain the uri or url to that file, f.i. @identifier="http://www.regionaalarchieftilburg.nl/archiefvormers/78910" (which is a fake url, just for the example).

Note: the EAD3 element <part/> doesn't allow the attribute @normal at the moment, nor does it allow <date/> as sub-element; however, a change request has been registered which will probably lead to allow the sub-element <date/> within <part/>, which will lead to the possibility to normalise dates within <part/>; from that moment on, the above mentioned <part localtype="dates"/> can be changed into:

<part localtype="dates" rules="apetypes" lang="dut">
    <date @normal="1917-01-01/1917-05-27">1 januari 1917 - 21 mei 1917</date>
</part>


ABSTRACT (optional for EAD3 and for an AFA)

This optional element could contain a short description of the material described, as a further explanation of the value of <titleproper/> and <subtitle/> (see above) and it would be good practice to add the optional attribute @lang to this. For the AFA NL-TbRAT-115_916 this could be the description that is given on the first page of the descriptive unit.

Example:

<abstract lang="dut">Repertoire der Akten, verleden voor Christoffel Johan Meindert Huefke, candidaat notaris plaats vervanger te Tilburg, 
waarnemende het vacante kantoor van den overleden notaris Petrus Hubertus Loven, serdert den eersten Januari negentien hondert
zeventien tot en met een en twintig Mei negentien honderd zeventien.</abstract>


MAIN PART 2b: /EAD/ARCHDESC/DSC

The element <dsc/> itself can contain an attribute @dsctype, for which the values are limited to: "analyticover", "combined", "in-depth" and "otherdsctype"; for FA's usually "combined" can be applied, but for AFA's we recommend "in-depth".

Example:

<dsc dsctype="in-depth">


There are no mandatory elements for the /ead/archdesc/dsc-part of an EAD3 FA, but it can contain these elements: <blockquote/>, <c/>, <c01/> etc., <chronlist/>, <head/>, <list/>, <p/>, <table/>, <thead/>, and of course all their dependencies.

For an AFA we recommend to at least use the following elements: <c/>, <c01/> etc., <chronlist/>, <head/>, <p/>, and within those: <chronitem/>, <corpname/>, <did/>, <dao/>, <daoset/>, <datesingle/>, <event/>, <famname/>, <genreform/>, <geogname/>, <part/>, <persname/>, <scopecontent/>, <unitdate/>, <unitid/>, <unittitle/>, and all their possible dependencies of course.

ARCHDESC/DSC/HEAD (optional for EAD3 and for an AFA)

This optional element can contain a title indicating the content of this part of the (A)FA, f.i.: "Description of the descriptive unit in detail" or (in Dutch): "Beschrijving van het archiefbestanddeel in detail".

Example:

<head>Description of the descriptive unit in detail</head>


ARCHDESC/DSC/C (optional for EAD3, but mandatory for an AFA)

In the case of an AFA the element <c/> (or <c01/>, etc.) needs to have the value "item" for the attribute @level:

<c level="item">

Since opening up Notary records via AFA's can be done via two different approaches: either copying the information from an index on Notary records (in Dutch "Repertorium") to an AFA or copying the information of all full Notary records to an AFA (but in both approaches including links to the scans of the full Notary records), we will provide a separate guideline for these two methods here (see above)

ARCHDESC/DSC/C for an AFA decribing an index on Notary records

A description at c-level of an AFA describing the items of an index ("Repertorium") on Notary records, so in fact an example of one item of an index ("Repertorium"), will look like this in an EAD3 AFA:

<c level="item">
	<did>
		<unitid>1</unitid>
		<unittitle localtype="notary_record" lang="dut">Inventaris der nalatenschap van Ludovicus Broeckx overleden te 
                Bergen op Zoom 30 november 1916 door zijne weduwe Wilhelmina Adriana Anna Maria Stokkermans
			<genreform>
				<part localtype="type_record" rules="apetypes" lang="dut">minuut</part>
				<part localtype="subject_record" rules="apetypes" lang="dut">inventaris</part>
			</genreform>
		</unittitle>
		<unitdate calendar="gregorian" era="ce" normal="1917-01-02">2 januari 1917</unitdate>
		<daoset coverage="part">
			<dao daotype="derived" coverage="part" actuate="onload" show="embed" linktitle="akte no. 1" localtype="thumbnail"
                        href="[url to thumbnail]"/>
			<dao daotype="derived" coverage="part" actuate="onrequest" show="new" linktitle="akte no. 1" localtype="fullsize" 
                        href="[url to full sized
                        scan"/>
		</daoset>
	</did>
	<scopecontent>
		<chronlist>
			<chronitem>
				<datesingle standarddate="1917-01-02">2 januari 1917</datesingle>
				<event localtype="inventaris">
					<persname relator="subject" rules="apetypes">
						<part localtype="firstname" rules="apetypes" lang="dut">Ludovicus</part>
						<part localtype="lastname" rules="apetypes" lang="dut">Broeckx</part>
						<part localtype="gender" rules="apetypes" lang="dut">man</part>
						<part localtype="role" rules="apetypes" lang="dut">overledene</part>
						<part localtype="deathdate" rules="apetypes" lang="dut">30 november 1916</part>
					</persname>
					<persname relator="actor" rules="apetypes">
						<part localtype="firstname" rules="apetypes" lang="dut">Wilhelmina Adriana Anna Maria</part>
						<part localtype="lastname" rules="apetypes" lang="dut">Stokkermans</part>
						<part localtype="gender" rules="apetypes" lang="dut">vrouw</part>
						<part localtype="role" rules="apetypes" lang="dut">weduwe</part>
					</persname>
					<geogname identifier="http://www.geonames.org/2746301">
						<part>Tilburg</part>
						<geographiccoordinates coordinatesystem="WGS84">51.560596, 5.091914</geographiccoordinates>
					</geogname>
					<subject>
						<part localtype="onderwerp" rules="apetypes" lang="dut">nalatenschap</part>
					</subject>
				</event>
			</chronitem>
		</chronlist>
	</scopecontent>
</c>


As you can see it's recommended to use two parts for the information that has to be stored in the <c/> (or <c01/>, etc.) elements: <did/> and <scopecontent/>; the <did/>-part has to contain the general information on the item of the index ("Repertorium") it describes, including the full text as well as the links to the scans of the actual full Notary record, and the <scopecontent/>-part has to contain more detailed information on the event and the persons described in the item of the index ("Repertorium").

ARCHDESC/DSC/C/DID for an AFA decribing an index on Notary records

The /archdesc/dsc/c/did-element for an AFA describing an item of an index on Notary records has to contain at least these elements: <unitid/>, <unittitle/>, <unitdate/> and <daoset/>, including their dependencies:

This element has to contain the number of the item in the index ("Repertorium"):

Example:

<unitid>1</unitid>


This element has to contain the full text of the item in the index ("Repertorium") and furhtermore it's mandatory to add the attribute @localtype to it, for storing information on which kind of an AFA this information is from; this attribute can contain a lot of values for different kind of AFA's (see: the localtype values list), but for an AFA on Notary records it has to contain the value: "notary_record"; it's recommended to add the attribute @lang indicating the language of the description.

It has to contain the sub-element <genreform/>, consisting of two sub-elements <part/>, having an attribute @localtype, which enables specifying the type and the subject of Notary records in more detail; following the localtype values list, one <part/> has to have as @localtype value: "type_record" and the value for the Dutch Notary records for this <part/> has to be either: "brevet" or "minuut" (this is an administrative distinction between types of Notary records), and the other <part/> has to have as @localtype value "subject_record" and the value for this <part/> can be derived from the localtype values list and tells something about the subject of the Notary record; for the example, the subject of the Notary record is: "inventaris", which is Dutch for "inventory", because it's about drafting an inventory of the belongings of a deceased person; for identifying the list of @localtype values, the attribute @rules has to be added and it is also recommended to use the attribute @lang for indicating the language of these values.

Example:

<unittitle localtype="notary_record" lang="dut">Inventaris der nalatenschap van Ludovicus Broeckx overleden te Bergen op Zoom
        30 november 1916 door zijne weduwe Wilhelmina Adriana Anna Maria Stokkermans
	<genreform>
		<part localtype="type_record" rules="apetypes" lang="dut">minuut</part>
		<part localtype="subject_record" rules="apetypes" lang="dut">inventaris</part>
	</genreform>
</unittitle>


The value for this element has to be the date of the item in the index ("Repertorium"), so the date of the actual Notary record; the <unitdate/> can contain a few attributes of which only one is mandatory:

  • @calendar, optional, indicating the system used for registering time, this attribute can contain as values: "gregorian" or "julian", most of the time "gregorian" will have to be used;
  • @era, optional, indicating the period of time during which the dates were used, this attribute can contain as values: "ce" (= common era) or "bce" (= before common era), most of the time "ce" will have to be used;
  • @normal, mandatory, containing the standardised form of the date according to the ISO 8601 standard.

Example:

<unitdate calendar="gregorian" era="ce" normal="1917-01-02">2 januari 1917</unitdate>

Note: see for more possibilities to 'tag' dates and date ranges and their normalisation above.

This element is meant to contain links to the scans of the actual Notary record; per scan two links are recommended: one to a thumbnail of the scan and one to the full sized scan (as presented on the website of the Archives Portal Europe's content provider), but only the second one is mandatory. In case a full Notary record has more than one scan (so has more than one page/folio), then per scan this set of two links (of which - again - only the second one is mandatory) has to be provided.

The element <daoset/> itself can contain several optional attributes of which one in particular is recommended: @coverage, for which the values are limited to: "part" and "whole"; for describing items in AFA's usually "part" will have to be applied, because the links within the <daoset/>-element point to only a part of a whole set of scans.

Example:

<daoset coverage="part">

Within the element <daoset/> the sub-element <dao/> has to be used for each link to a scan, whether to the thumbnail of the scan or the full sized scan; the sub-element <dao/> has to contain the following mandatory attributes:

  • @daotype, this indicates the origin of a digital object: born digital, or a scan of a non digital record; this attribute can contain four different values: "borndigital", "derived", "otherdaotype", "unknown"; for digitised material to be linked to an AFA, the value: "derived" has to be used;
  • @coverage,
  • @actuate, this attribute is meant to define how the link to a scan should be presented; it can contain two values: "onload" and "onrequest"; the first value is used for a link to a thumbnail and the second one is used for a link to a full sized scan (so a thumbnail should always be shown, and a full sized scan only when a user asks for it);
  • @show, this attribute is always used in combination with the previous one (@actuate); it can contain four values: "new", "replace", "embed", "other" and "none"; the value "embed" is used for a link to a thumbnail and the value "new" is used for a link to a full sized scan;
  • @linktitle, this attribute can contain a caption for the scan to which the link points, so its value might be a Notary record number, a page or folio number;
  • @localtype, in the context of linking to digital objects, this attribute can define the sort of link that is produced; the value: "thumbnail" is used for a link to a thumbnail and the value: "fullsize" is used for a link to a full sized scan;
  • @href, in the context of linking to digital objects, this attribute has to contain the url to the thumbnail or full sized scan, the latter as presented on the website of the Archives Portal Europe's content provider.

Example:

<daoset coverage="part">
	<dao daotype="derived" coverage="part" actuate="onload" show="embed" linktitle="akte no. 1" localtype="thumbnail" 
        href="[url to thumbnail]"></dao>
	<dao daotype="derived" coverage="part" actuate="onrequest" show="new" linktitle="akte no. 1" localtype="fullsize" 
        href="[url to full sized scan]"></dao>
</daoset>


ARCHDESC/DSC/C/SCOPECONTENT for an AFA decribing an index on Notary records

The /archdesc/dsc/c/scopecontent-element for an AFA describing an item of an index on Notary records can contain these elements: <blockquote/>, <chronlist/>, <head/>, <list/>, <p/>, <scopecontent/> and <table/>, including their dependencies.

For use within the /ead/archdesc/c/scopecontent-element of an AFA it's recommended to use the sub-element <chronlist/> and its sub-element <chronitem/>, which can contain the sub-elements: <chronitemset/>, <daterange/>, <dateset/>, <datesingle/>, <event/> and <geogname/>, and within <event/> it's not only possible to describe the nature of events, but also the persons, locations and objects related to them.

This element is a wrapper element for giving access to the (chronological) description of one or more significant events, which have to be described within its sub-element <chronitem/>.

This element is meant to connect a date (<datesingle/>) or date range (<daterange/>) with one or more <event/>'s and one or more geographical names (<geogname/>).

This element is meant to provide a date for the event described within <chronitem/>, most of the time it will be the same date as provided in the <unitdate/> within the /ead/archdesc/dsc/c/did-part of an AFA (see above); within <datesingle/> the normalisation of the date takes place via the attribute @standarddate:

Example:

<datesingle standarddate="1907-01-02">2 januari 1917</datesingle>


This element is meant to provide a date range for the event described within <chronitem/> and it can contain the sub-elements <fromdate/> and <todate/> and of course these can be normalised using the attribute @standarddate:

<daterange>
        <fromdate @standarddate="1917-01-01>1 januari 1917</fromdate>
        <todate @standarddate="1917-05-21>21 mei 1917</todate>
</daterange>


This element is meant to describe an event in full detail including persons, locations and objects involved; it can contain the following sub-elements: <abbr/>, <corpname/>, <date/>, <emph/>, <expan/>, <famname/>, <footnote/>, <foreign/>, <function/>, <genreform/>, <geogname/>, <lb/>, <list/>, <name/>, <num/>, <occupation/>, <persname/>, <ptr/>, <quote/>, <subject/>, <title/>.

For an AFA the following sub-elements are recommended: <corpname/>, <famname/>, <geogname/>, <name/>, <persname/> and <subject/>.

The element <event/> itself doesn't have to contain a value, only an attribute @localtype (mandatory for AFA's), for storing information on which kind of an event is described; for an AFA on Notary records this will have to be the same value as the one for /ead/archdesc/dsc/c/did/unittitle//genreform/part @localtype="subject_record" (see above), so in the case of the example: "inventaris".

Example:

<event localtype="inventaris">


For these elements goes the same as what has been stated for them when describing their use within /ead/archdesc/did/origination (see above); of course these elements can occur more than once within <event/>; within an AFA most of the time <persname/> will be used:

Example:

<persname relator="subject" rules="apetypes">
	<part localtype="firstname" rules="apetypes" lang="dut">Ludovicus</part>
	<part localtype="lastname" rules="apetypes" lang="dut">Broeckx</part>
	<part localtype="gender" rules="apetypes" lang="dut">man</part>
	<part localtype="role" rules="apetypes" lang="dut">overledene</part>
	<part localtype="deathdate" rules="apetypes" lang="dut">30 november 1916</part>
</persname>
<persname relator="actor" rules="apetypes">
	<part localtype="firstname" rules="apetypes" lang="dut">Wilhelmina Adriana Anna Maria</part>
	<part localtype="lastname" rules="apetypes" lang="dut">Stokkermans</part>
	<part localtype="gender" rules="apetypes" lang="dut">vrouw</part>
	<part localtype="role" rules="apetypes" lang="dut">weduwe</part>
</persname>

Note: see for all possible values of the attribute @relator and of the attribute @localtype of the sub-element <part/> the localtype values list.

If you come across a list of items, f.i. an inventory of a house or a list of debts, then you can use the sub-element <list/>, which can have as attribute @listtype to indicate what kind of list it is: "deflist", "ordered" or "unordered", which might have a <head/>-element for indicating what the list is all about, and must have one or more <item/>-elements containing the items of the list.

Example:

<list listtype="unordered">
	<head>schuldbekentenissen</head>
	<item>drie obligatiën nieuwe Koninklijke Harmonie ieder groot vijftig gulden, genummerd 353-352-1, met de coupons van 
        vijftien October aanstaande en talons.</item>
	<item>schuldbekentenis ten laste van den heer Adrianus Broekx van Alphen, comparant sub II, groot vijf duizend gulden rentende
        vier percent 's jaars per een november, onder borgtocht van den heer Antonius Josephus Broekx comparant sub III voor de betaling
        der rente. Omtrent deze obligatie verklaarde de aangeefster dat daarvan de rente over de jaren negentienhonderd dertien en volgende
        niet is betaald.</item>
	<item>schuldbekentenis ten laste van den heer Josephus Maria Broekx, comparant sub IV, groot drie duizend gulden, rentende vier
        percent 's jaars op vijf en twintig April, waaromtrent de aangeefster verklaarde dat hiervan de rente sedert den laatsten vervaldag
        schuldig is.</item>
	<item>schuldbekentenis ten laste van den heer Hubert Stokkermans bloemist te Tilburg groot drie honderd zesentwintig gulden twintig
        cent, rentende drie percent 's jaars op twintig Januari, waaromtrent de aangeefster verklaarde dat deze rente sedert het ontstaan
        der vordering in achttien honderd vijf en negentig schuldig is</item>
	<item>schuldbekentenis ten laste van den heer Alphonse Josephus van den Brekel comparant sub V wegens saldo van rekening zes honderd
        negen en dertig gulden twee en zeventig en een halve cent.</item>
</list>


This element is meant to contain the geographical name at which the event took place; for Notary records this will most of the time be the location of the Notary office; it can have several optional attributes, among which @identifier is the most useful, so recommended one, for storing a uri or url to controlled vocabularies or authority file systems, like http://www.geonames.org/.

Furthermore it has to contain a mandatory sub-element <part/> in which the name of the geographical location has to be stored and this sub-element can be used more than once, f.i. for complicated geographical names; it can also contain the optional sub-element <geographiccoordinates/>, using the attribute @coordinatesystem, in which the exact coordinates of the geographical name can be stored:

Example:

<geogname identifier="http://www.geonames.org/2746301">
	<part>Tilburg</part>
	<geographiccoordinates coordinatesystem="WGS84">51.560596, 5.091914</geographiccoordinates>
</geogname>

Note: tools for getting geographical coordinates of a place are: https://itouchmap.com/latlong.html and http://twcc.fr.

This element is meant to describe topics that are referred to in the Notary records; it can have as attributes @localtype and @identifier, for indicating the type of topic and connect it to controlled vocabularies or authority file systems; it has to contain (mandatory) one or more sub-elements <part/> in which the topic term can be stored, as a whole or in parts in case of complicated topics.

Next to the attributes @localtype and @rules, it's recommended to also use the attribute @lang to indicate the language of the description.

Example:

<subject>
	<part localtype="topic" rules="apetypes" lang="dut">nalatenschap</part>
</subject>

Note: see for all possible values of the attribute @localtype and of the sub-element <part/> the localtype values list.

ARCHDESC/DSC/C, /DID and /SCOPECONTENT for an AFA decribing all full Notary records

Basically creating an AFA describing all full Notary records at c-level, so in fact providing one full Notary record description per c-level, comes down to re-using all the different parts of an (A)FA as described above, only this time using these to provide much more detail.

Note: if there is an index ("Repertorium") available for a set of full Notary records that are to be described, then it's recommended to re-use the descriptions of the index ("Repertorium") for the <untittitle/>'s of the individual full Notary records.

Here is an example of a c-level in EAD3 of an AFA describing all Notary records in full detail:

  • since Notary record number 1 of the sample file NL-TbRAT-115_871 (see above) consists of nine scans, the /EAD/ARCHDESC/DSC/C/DID-part will look like this:
<c level="item">
	<did>
	        <unitid>1</unitid>
		<unittitle localtype="notary_record" lang="dut">Inventaris der nalatenschap van Ludovicus Broeckx overleden 
                te Bergen op Zoom 30 november 1916 door zijne weduwe Wilhelmina Adriana Anna Maria Stokkermans
			<genreform>
				<part localtype="type_record" rules="apetypes" lang="dut">minuut</part>
				<part localtype="subject_record" rules="apetypes" lang="dut">inventaris</part>
			</genreform>
		</unittitle>
		<unitdate calendar="gregorian" era="ce" normal="1917-01-02">2 januari 1917</unitdate>
		<daoset coverage="part">
			<dao daotype="derived" coverage="part" actuate="onload" show="embed" linktitle="akte no. 1, folio 1"
                        localtype="thumbnail" href="[url to thumbnail]"/>
			<dao daotype="derived" coverage="part" actuate="onrequest" show="new" linktitle="akte no. 1, folio 1"
                        localtype="fullsize" href="[url to full sized scan]"/>
			<dao daotype="derived" coverage="part" actuate="onload" show="embed" linktitle="akte no. 1, folio 2"
                        localtype="thumbnail" href="[url to thumbnail]"/>
			<dao daotype="derived" coverage="part" actuate="onrequest" show="new" linktitle="akte no. 1, folio 2"
                        localtype="fullsize" href="[url to full sized scan]"/>
			<dao daotype="derived" coverage="part" actuate="onload" show="embed" linktitle="akte no. 1, folio 3"
                        localtype="thumbnail" href="[url to thumbnail]"/>
			<dao daotype="derived" coverage="part" actuate="onrequest" show="new" linktitle="akte no. 1, folio 3"
                        localtype="fullsize" href="[url to full sized scan]"/>
			<dao daotype="derived" coverage="part" actuate="onload" show="embed" linktitle="akte no. 1, folio 4"
                        localtype="thumbnail" href="[url to thumbnail]"/>
			<dao daotype="derived" coverage="part" actuate="onrequest" show="new" linktitle="akte no. 1, folio 4"
                        localtype="fullsize" href="[url to full sized scan]"/>
			<dao daotype="derived" coverage="part" actuate="onload" show="embed" linktitle="akte no. 1, folio 5" 
                        localtype="thumbnail" href="[url to thumbnail]"/>
			<dao daotype="derived" coverage="part" actuate="onrequest" show="new" linktitle="akte no. 1, folio 5"
                        localtype="fullsize" href="[url to full sized scan]"/>
			<dao daotype="derived" coverage="part" actuate="onload" show="embed" linktitle="akte no. 1, folio 6"
                        localtype="thumbnail" href="[url to thumbnail]"/>
			<dao daotype="derived" coverage="part" actuate="onrequest" show="new" linktitle="akte no. 1, folio 6" 
                        localtype="fullsize" href="[url to full sized scan]"/>
			<dao daotype="derived" coverage="part" actuate="onload" show="embed" linktitle="akte no. 1, folio 7" 
                        localtype="thumbnail" href="[url to thumbnail]"/>
			<dao daotype="derived" coverage="part" actuate="onrequest" show="new" linktitle="akte no. 1, folio 7"
                        localtype="fullsize" href="[url to full sized scan]"/>
			<dao daotype="derived" coverage="part" actuate="onload" show="embed" linktitle="akte no. 1, folio 8"
                        localtype="thumbnail" href="[url to thumbnail]"/>
			<dao daotype="derived" coverage="part" actuate="onrequest" show="new" linktitle="akte no. 1, folio 8"
                        localtype="fullsize" href="[url to full sized scan]"/>
			<dao daotype="derived" coverage="part" actuate="onload" show="embed" linktitle="akte no. 1, folio 9"
                        localtype="thumbnail" href="[url to thumbnail]"/>
			<dao daotype="derived" coverage="part" actuate="onrequest" show="new" linktitle="akte no. 1, folio 9"
                        localtype="fullsize" href="[url to full sized scan]"/>
		</daoset>
	</did>


  • since Notary record number 1 of the sample file NL-TbRAT-115_871 (see above) contains a lot more information on persons compared to whats stated about this record in the index ("Repertorium"), NL-TbRAT-115_971 (see above), the /EAD/ARCHDESC/DSC/C/SCOPECONTENT-part will look like this:
<scopecontent>
	<chronlist>
		<chronitem>
			<datesingle standarddate="1917-01-02">2 januari 1917</datesingle>
			<event localtype="inventaris">
				<persname relator="actor" rules="apetypes">
					<part localtype="firstname" rules="apetypes" lang="dut">Wilhelmina Adriana Anna Maria</part>
					<part localtype="lastname" rules="apetypes" lang="dut">Stokkermans</part>
					<part localtype="gender" rules="apetypes" lang="dut">vrouw</part>
					<part localtype="occupation" rules="apetypes" lang="dut">geen</part>
					<part localtype="residence" rules="apetypes" lang="dut">Bergen op Zoom</part>
					<part localtype="role" rules="apetypes" lang="dut">tweede vrouw en weduwe van Ludovicus Broekx</part>
					<part localtype="remark" rules="apetypes" lang="dut">comparant I</part>
				</persname>
				<persname relator="creditor" rules="apetypes">
					<part localtype="firstname" rules="apetypes" lang="dut">Adrianus Cornelis Maria</part>
					<part localtype="lastname" rules="apetypes" lang="dut">Broekx</part>
					<part localtype="gender" rules="apetypes" lang="dut">man</part>
					<part localtype="occupation" rules="apetypes" lang="dut">geen</part>
					<part localtype="residence" rules="apetypes" lang="dut">Teteringen</part>
					<part localtype="remark" rules="apetypes" lang="dut">comparant II</part>
				</persname>
				<persname relator="creditor" rules="apetypes">
					<part localtype="firstname" rules="apetypes" lang="dut">Antonius Josephus</part>
					<part localtype="lastname" rules="apetypes" lang="dut">Broekx</part>
					<part localtype="gender" rules="apetypes" lang="dut">man</part>
					<part localtype="occupation" rules="apetypes" lang="dut">hotelhouder</part>
				        <part localtype="residence" rules="apetypes" lang="dut">Tilburg</part>
					<part localtype="role" rules="apetypes" lang="dut">lasthebber van eerwaarde zuster Maria Louisa 
                                        Josephina Broekx</part>
					<part localtype="remark" rules="apetypes" lang="dut">comparant III</part>
				</persname>
				<persname relator="creditor" rules="apetypes">
					<part localtype="firstname" rules="apetypes" lang="dut">Maria Louisa Josephina</part>
					<part localtype="lastname" rules="apetypes" lang="dut">Broekx</part>
					<part localtype="gender" rules="apetypes" lang="dut">vrouw</part>
					<part localtype="occupation" rules="apetypes" lang="dut">religieuze</part>
					<part localtype="residence" rules="apetypes" lang="dut">Antwerpen</part>
					<part localtype="role" rules="apetypes" lang="dut">lastgever aan Antonius Josephus Broekx</part>
				</persname>
				<persname relator="creditor" rules="apetypes">
					<part localtype="firstname" rules="apetypes" lang="dut">Josephus Henri Emile</part>
					<part localtype="lastname" rules="apetypes" lang="dut">Delhaye</part>
					<part localtype="gender" rules="apetypes" lang="dut">man</part>
					<part localtype="maritalstatus" rules="apetypes" lang="dut">zonder huwelijksvoorwaarden gehuwd met
                                        mejuffrouw Joanna Bernardina MariaBroekx</part>
					<part localtype="occupation" rules="apetypes" lang="dut">koopman</part>
					<part localtype="residence" rules="apetypes" lang="dut">Chicago</part>
					<part localtype="role" rules="apetypes" lang="dut">lasthebber van mejuffrouw Joanna Bernardina 
                                        Maria Broekx</part>
				</persname>
				<persname relator="creditor" rules="apetypes">
					<part localtype="firstname" rules="apetypes" lang="dut">Joanna Bernardina Maria</part>
					<part localtype="lastname" rules="apetypes" lang="dut">Broekx</part>
					<part localtype="gender" rules="apetypes" lang="dut">vrouw</part>
					<part localtype="maritalstatus" rules="apetypes" lang="dut">zonder huwelijksvoorwaarden gehuwd met
                                        Josephus Henri
                                        Emile Delhaye</part>
					<part localtype="role" rules="apetypes" lang="dut">lastgever aan Josephus Henri Emile</part>
				</persname>
				<persname relator="creditor" rules="apetypes">
					<part localtype="firstname" rules="apetypes" lang="dut">Joseph Maria</part>
					<part localtype="lastname" rules="apetypes" lang="dut">Broekx</part>
					<part localtype="gender" rules="apetypes" lang="dut">man</part>
					<part localtype="occupation" rules="apetypes" lang="dut">koopman</part>
					<part localtype="residence" rules="apetypes" lang="dut">Hilversum</part>
					<part localtype="remark" rules="apetypes" lang="dut">comparant IV</part>
				</persname>
				<persname relator="creditor" rules="apetypes">
					<part localtype="firstname" rules="apetypes" lang="dut">Alphonse Josephus</part>
					<part localtype="infix" rules="apetypes" lang="dut">van den</part>
					<part localtype="lastname" rules="apetypes" lang="dut">Brekel</part>
					<part localtype="gender" rules="apetypes" lang="dut">man</part>
					<part localtype="maritalstatus" rules="apetypes" lang="dut">zonder huwelijksvoorwaarden gehuwd met
                                        mejuffrouw Cornelia Maria Joanna Broekx</part>
					<part localtype="occupation" rules="apetypes" lang="dut">koopman</part>
					<part localtype="residence" rules="apetypes" lang="dut">Tilburg</part>
					<part localtype="remark" rules="apetypes" lang="dut">comparant V</part>
				</persname>
				<persname relator="creditor" rules="apetypes">
					<part localtype="firstname" rules="apetypes" lang="dut">Cornelia Maria Joanna</part>
					<part localtype="lastname" rules="apetypes" lang="dut">Broekx</part>
					<part localtype="gender" rules="apetypes" lang="dut">vrouw</part>
					<part localtype="maritalstatus" rules="apetypes" lang="dut">zonder huwelijksvoorwaarden gehuwd met
                                        Alphonse Josephus van den Brekel</part>
				</persname>
				<persname relator="subject" rules="apetypes">
					<part localtype="firstname" rules="apetypes" lang="dut">Ludovicus</part>
					<part localtype="lastname" rules="apetypes" lang="dut">Broeckx</part>
					<part localtype="gender" rules="apetypes" lang="dut">man</part>
					<part localtype="role" rules="apetypes" lang="dut">overledene, gehuwd geweest met Wilhelmina
                                        Adriana Anna Maria Stokkermans</part>
					<part localtype="deathdate" rules="apetypes" lang="dut">30 november 1916</part>
					<part localtype="deathplace" rules="apetypes" lang="dut">Bergen op Zoom</part>
				</persname>
				<persname relator="subject_child" rules="apetypes">
					<part localtype="firstname" rules="apetypes" lang="dut">Joanna Bernardina Maria</part>
					<part localtype="lastname" rules="apetypes" lang="dut">Broeckx</part>
					<part localtype="gender" rules="apetypes" lang="dut">vrouw</part>
					<part localtype="role" rules="apetypes" lang="dut">nog in leven zijnd kind van de overledene</part>
				</persname>
				<persname relator="subject_child" rules="apetypes">
					<part localtype="firstname" rules="apetypes" lang="dut">Adrianus Cornelius Maria</part>
					<part localtype="lastname" rules="apetypes" lang="dut">Broeckx</part>
					<part localtype="gender" rules="apetypes" lang="dut">man</part>
					<part localtype="role" rules="apetypes" lang="dut">nog in leven zijnd kind van de overledene</part>
				</persname>
				<persname relator="subject_child" rules="apetypes">
					<part localtype="firstname" rules="apetypes" lang="dut">Antonius Joseph</part>
					<part localtype="lastname" rules="apetypes" lang="dut">Broeckx</part>
					<part localtype="gender" rules="apetypes" lang="dut">man</part>
					<part localtype="role" rules="apetypes" lang="dut">nog in leven zijnd kind van de overledene</part>
				</persname>
				<persname relator="subject_child" rules="apetypes">
					<part localtype="firstname" rules="apetypes" lang="dut">Joseph Maria</part>
					<part localtype="lastname" rules="apetypes" lang="dut">Broeckx</part>
					<part localtype="gender" rules="apetypes" lang="dut">man</part>
					<part localtype="role" rules="apetypes" lang="dut">nog in leven zijnd kind van de overledene</part>
				</persname>
				<persname relator="subject_child" rules="apetypes">
					<part localtype="firstname" rules="apetypes" lang="dut">Maria Louisa Josephina</part>
					<part localtype="lastname" rules="apetypes" lang="dut">Broeckx</part>
					<part localtype="gender" rules="apetypes" lang="dut">vrouw</part>
					<part localtype="role" rules="apetypes" lang="dut">nog in leven zijnd kind van de overledene</part>
				</persname>
				<persname relator="actor" rules="apetypes">
					<part localtype="firstname" rules="apetypes" lang="dut">Antonius Petrus Adrianus</part>
					<part localtype="lastname" rules="apetypes" lang="dut">Storimans</part>
					<part localtype="gender" rules="apetypes" lang="dut">man</part>
					<part localtype="occupation" rules="apetypes" lang="dut">meubelmaker</part>
					<part localtype="residence" rules="apetypes" lang="dut">Bergen op Zoom</part>
					<part localtype="role" rules="apetypes" lang="dut">inboedel taxateur</part>
				</persname>
				<persname relator="creditor" rules="apetypes">
					<part localtype="firstname" rules="apetypes" lang="dut">Hubert</part>
					<part localtype="lastname" rules="apetypes" lang="dut">Stokkermans</part>
					<part localtype="gender" rules="apetypes" lang="dut">man</part>
					<part localtype="occupation" rules="apetypes" lang="dut">bloemist</part>
					<part localtype="residence" rules="apetypes" lang="dut">Tilburg</part>
				</persname>
				<persname relator="mentioned" rules="apetypes">
					<part localtype="initials" rules="apetypes" lang="dut">J.N.</part>
					<part localtype="infix" rules="apetypes" lang="dut">de</part>
					<part localtype="lastname" rules="apetypes" lang="dut">Pont</part>
					<part localtype="gender" rules="apetypes" lang="dut">man</part>
					<part localtype="occupation" rules="apetypes" lang="dut">schoenfabrikant</part>
					<part localtype="residence" rules="apetypes" lang="dut">Tilburg</part>
					<part localtype="remark" rules="apetypes" lang="dut">huurder van een woonhuis in de Heuvelstraat
                                        Tilburg, kadastraal bekend als sectie M, nummer 2880</part>	
               			</persname>
				<persname relator="mentioned" rules="apetypes">
					<part localtype="initials" rules="apetypes" lang="dut">B.H.C.</part>
					<part localtype="infix" rules="apetypes" lang="dut">de</part>
					<part localtype="lastname" rules="apetypes" lang="dut">Pont</part>
					<part localtype="gender" rules="apetypes" lang="dut">man</part>
					<part localtype="occupation" rules="apetypes" lang="dut">schoenfabrikant</part>
					<part localtype="residence" rules="apetypes" lang="dut">Tilburg</part>
					<part localtype="remark" rules="apetypes" lang="dut">huurder van een woonhuis in de Heuvelstraat
                                        Tilburg, kadastraal bekend als sectie M, nummer 2880</part>
				</persname>
				<list listtype="unordered">
					<head>schuldbekentenissen</head>
					<item>drie obligatiën nieuwe Koninklijke Harmonie ieder groot vijftig gulden, genummerd 353-352-1,
                                        met de coupons van vijftien October aanstaande en talons.</item>
					<item>schuldbekentenis ten laste van den heer Adrianus Broekx van Alphen, comparant sub II, groot
                                        vijf duizend gulden rentende vier percent 's jaars per een november, onder borgtocht van den heer
                                        Antonius Josephus Broekx comparant sub III voor de betaling der rente. Omtrent deze obligatie 
                                        verklaarde de aangeefster dat daarvan de rente over de jaren negentienhonderd dertien en volgende 
                                        niet is betaald.</item>
					<item>schuldbekentenis ten laste van den heer Josephus Maria Broekx, comparant sub IV, groot drie
                                        duizend gulden, rentende vier percent 's jaars op vijf en twintig April, waaromtrent de aangeefster 
                                        verklaarde dat hiervan de rente sedert den laatsten vervaldag schuldig is.</item>
					<item>schuldbekentenis ten laste van den heer Hubert Stokkermans bloemist te Tilburg groot drie 
                                        honderd zesentwintig gulden twintig cent, rentende drie percent 's jaars op twintig Januari, 
                                        waaromtrent de aangeefster verklaarde dat deze rente sedert het ontstaan der vordering in achttien
                                        honderd vijf en negentig schuldig is</item>
					<item>schuldbekentenis ten laste van den heer Alphonse Josephus van den Brekel comparant sub V wegens
                                        saldo van rekening zes honderd negen en dertig gulden twee en zeventig en een halve cent.</item>
				</list>
				<list listtype="unordered">
					<head>onroerende goederen te Tilburg</head>
					<item>Het gebouw aan de Spoorlaan ingericht voor hotel woonhuis en café-restaurant. Kadastraal
                                        bekend sectie nummer 3864 groot drie Arennaren en dertig Centiaren, hetwelk blijkens in den boedel
                                        voorhanden huurcontracten is verhuurd aan den heer Antonius Josephus Broekx voornoemd, tegen vijftien
                                        honderd gulden per jaar. Zijnde in dit huurcontract vermeld, dat de huurder het recht van koop heeft
                                        voor de som van dertig duizend gulden.</item>
					<item>De perceelen winkel en woonhuizen aan de Heuvelstraat te Tilburg, aldaar kadastraal bekend
                                        sectie M nummers 2879 en 2880 samen groot twee Aren. Waarvan het eene is verhuurd aan den heer Hubert
                                        Stokkermans bloemist en voor de huursom van vijf honderd vijftig gulden, ingevolge monderlinge
                                        overeenkomst en het andere blijkens in den boedel voorhanden huurcontract aan de heren J.N. de Pont 
                                        en B.H.C. de Pont schoenfabrikanten voor acht honderd gulden per jaar.</item>
				</list>
				<geogname identifier="http://www.geonames.org/2746301">
					<part>Tilburg</part>
					<geographiccoordinates coordinatesystem="WGS84">51.560596, 5.091914</geographiccoordinates>
				</geogname>
				<subject>
					<part localtype="topic" lang="dut">nalatenschap</part>
                                </subject>
			</event>
		</chronitem>
	</chronlist>
</scopecontent>


Note: the sample file NL-TbRAT-115_871 doesn't contain all information of Notary record number 1 yet; this first part is just to give you an idea of what is possible.