Add new element <formAvailable> to encode any type of instantiations of the materials described

[kerstarno]

Creator of issue

1. Kerstin Arnold
2. EAD team lead, TS-EAS
3. @kerstarno
4. kerstin.arnold@archivesportaleurope.net

The issue relates to

• [ ] EAC-CPF schema issue
• [ ] EAC-CPF Tag Library issue
• [x] EAD schema issue
• [x] EAD Tag Library issue
• [ ] Schema issue
• [ ] Tag Library issue
• [ ] Suggestions for all schemas
• [ ] Suggestions for all Tag Libraries
• [ ] Other

Wanted change/feature

• Text: In reviewing EAD, the conceptual approaches to its elements and its relation to Records in Contexts, the EAD subteam has discussed the use of the elements <dao>, <altformavail> and <originalsloc> as representing variations of instantiations of the materials being described; either as digitised/born-digital representations, other forms like microfilm, or originals held by another institution or having been destroyed previously when the materials being described effectively represent copies of those originals. Along with <agent> (#58) and <function> (#61), a new element to represent this entity of instantiations is to be established, combining the three current elements.

Note for working on and testing this issue: When the schema changes are done in development branch, please mark the tasks on the highest levels of the list (printed in bold) by ticking the box. When the changes have been tested successfully, please mark the tasks on the lowest level of the list.

• [x] Add a new element <formAvailable> as required and repeatable sub-element of <formsAvailable> (see #68)
  • [x] Allow for <abstract> as an optional, not repeatable sub-element of <formAvailable>
  • [x] Allow for an optional choice between <p> (repeatable) and <formattingExtension> (not repeatable, see #62) within <formAvailable>
  • [x] Allow for <relations> as an optional, not repeatable sub-element of <formAvailable> (see #33)
  • [x] Allow for the optional attributes @audience, @id, @target, @languageOfElement, @scriptOfElement, @conventionDeclarationReference, @maintenanceEventReference, @sourceReference, @localType, @localTypeDeclarationReference, @valueURI, @vocabularySource, @vocabularySourceURI, and @coverage in <formAvailable>
  • [x] Allow <formAvailable> to include attributes from any other namespace

As a result of the above:

• [x] Remove <altformavail> from EAD
• [x] Remove <originalsloc> from EAD
• [x] Remove <dao> and <daoset> from EAD
• [x] Remove @daotype and @otherdaotype from EAD

[fordmadox]

Should this element also get the @coverage attribute, to handle migrations from the former dao element?

[kerstarno]

Should this element also get the @coverage attribute, to handle migrations from the former dao element?

Ah, yes, indeed. <formAvailable> is meant to include @coverage. Thanks for spotting. Added to the description above.

[fordmadox]

Another thought: wouldn't the container element now make more sense here rather than the former did element? For instance, if the component described material that existed within a box (the original), but was also available on microfilm, as well as in digital form, then those first two forms would be associated with different containers (most likely). In previous versions of EAD, there wasn't an unambiguous way to make those connections / declarations, but with EAD4 there could be if the container element was moved, I'd think.

[kerstarno]

Tested with the XSD and the RNG and can confirm that the above changes have been implemented with the exception of having the attribute @coverage added as optional to <formAvailable>. I have created a pull request (#85) for the latter. Once this is merged and the schemas have been generate anew, this issue needs another quick round of testing.

With regard to the following:

Another thought: wouldn't the container element now make more sense here rather than the former did element? For instance, if the component described material that existed within a box (the original), but was also available on microfilm, as well as in digital form, then those first two forms would be associated with different containers (most likely). In previous versions of EAD, there wasn't an unambiguous way to make those connections / declarations, but with EAD4 there could be if the container element was moved, I'd think.

The conversation around <formAvailable> did indeed include the extended suggestion to also include <container> and <physDesc> (and its variations) as optional sub-elements of <formAvailable>. Not removing these elements from <identificationData>, though, but making them also available in this new context. With this, there also was an alternative name suggested, <formAndPlacement>.

<identificationData> would then always refer to the original material (might that be in analogue or digital form and independent of whether this original form still exists - e.g. in the case the paper originals have been destroyed, but digital forms exist) respectively the main form of the material as held by the institution creating the description (in case the institution only holds copies, with the originals then being referred to via <formAvailable> as one would have done with <originalsloc> previously).

For now, the EAD sub-team agreed not to include this change and to see whether examples supporting such a change would be submitted by the community during the call for comments. @fordmadox - please feel free to get back to your suggestion then.

As an additional note: <container> is not used that extensively in non-US/non-North-American contexts.

[fordmadox]

I'd definitely vote for container (and, possibly, any related physDesc elements) to only be available in whatever element the formAvailable element becomes, rather than provide both options (which always leads to the inevitable repetition of data, which can easily get out of synch). We definitely need to think of potential ASpace adoption here, as well, which uses the word "Instances" for what EAD4 is now calling "formsAvailable". Plus, there's the need to have the imports and exports in ASpace, and due to that, there shouldn't really be any ambiguity about the whereabouts of the container element (as there isn't with EAD2002, although EAD2002 has the unusual use of the parent attribute with container which could/should be rendered obsolete with EAD4).

Anyhow, this is ready for testing again!

[kerstarno]

Re-tested with the XSD and the RNG and can confirm that <formAvailable> now also allows for the @coverage attribute.

[kerstarno]

I'd definitely vote for container (and, possibly, any related physDesc elements) to only be available in whatever element the formAvailable element becomes, rather than provide both options (which always leads to the inevitable repetition of data, which can easily get out of synch). We definitely need to think of potential ASpace adoption here, as well, which uses the word "Instances" for what EAD4 is now calling "formsAvailable". Plus, there's the need to have the imports and exports in ASpace, and due to that, there shouldn't really be any ambiguity about the whereabouts of the container element (as there isn't with EAD2002, although EAD2002 has the unusual use of the parent attribute with container which could/should be rendered obsolete with EAD4).

Good point about @parent, which could (should?) indeed be replaced by @target in EAD 4.0. Though, as said, <container> isn't used that extensively in Europe, so I couldn't say from own experience whether there's a need for a specific attribute in this context? It seems, we have - unintentionally - removed @parent from <physLoc> where it also is available in EAD3, so we probably should align these two elements one way or the other.

With regard to the name: let's see what the call for comments brings. We were discussing this change in the context of looking at instantiations (RiC) respectively representations (PREMIS) initially.