Questionnaire

During the three year revision process, all elements and attributes in EAC-CPF 2010 were evaluated. Even with an impressive set of EAC-CPF files from projects like SNAC and aggregators like the Archives Portal Europe, the EAC-CPF team was not able to get examples for all available elements and attributes in EAC-CPF 2010. Some of the non-used elements and attributes were removed (e.g. or @accuracy within ).

When you are reviewing the proposal we would like you to especially think about the following questions and give us feedback on how we should proceed.

Language Encoding

Instead of working with two attributes to encode the language and the writing system of the element’s content or of other language declarations, the usage of IETF language tags allows users to encode the language and script in a single attribute. Will this change be useful in your institution’s workflow? Will it make your language encoding more feasible?

EAC-CPF 2010 approach:

<occupation>
    <term languageOfElement="de" scriptOfElement="Cyrl">полтергейст</term>
    <term languageOfElement="de" scriptOfElement="Latn">Poltergeist</term>
</occupation>

Proposal with IETF language encoding:

<occupation>
    <term languageOfElement="de-Cyrl-DE">полтергейст</term>
    <term languageOfElement="de-Latn-DE">Poltergeist</term>
</occupation>

Namespace

The included namespaces xml and xlink were removed, in order to simplify the processing, to dismantle any barriers when working with XML files, and also to align with EAD. This leads to new attributes, performing the same roles as the attributes used in the xml and xlink namespaces, called @id, @languageOfElement, and @base, and @linkRole, @linkTitle, and @href, respectively. We’re interested in feedback from our user communities about this approach. Is it easier to handle EAS XML files without external namespaces?

Examples

Use cases and examples are needed for the following EAC-CPF encoding concepts. The TS-EAS will use the examples to illustrate these encoding functions and will discuss the implications of submitted use cases.

  1. Multiple identities: If you have a real example of combining the description of more than one identity of an entity in one EAC-CPF file by using the element <multipleIdentities>, please share it with the TS-EAS.
  2. Evidence-based assertions: With EAC-CPF 2.0, it will be possible to add evidence-based assertions to the EAC-CPF instance.
  3. Alternative set: With the new concept to encode relations of the entity described in the EAC-CPF file to other CPF entities, but also to resources and functions, it might not be necessary any more to use the element <alternativeSet> to link to alternative authority records. If you use this element in your encoding, we’re interested to see your xml files and to learn about the element’s usage to determine if it is still necessary.
  4. Attribute @base: The optional attribute @base is derived from @xml:base and it is used to specify a base URI that is different from the base URI of the EAC-CPF instance to allow any relative URIs. We’d like to find out if this @base needs to be an optional attribute in other than the listed elements (<alternativeSet>, <control>, <cpfDescription>, <description>, <eac>, <identity>, <multipleIdentities>, <relations>, and <sources>).
  5. Attribute @target: The newly introduced attribute is optionally available in all elements, except <eac>, to create internal links within an XML instance. We’d like to learn from the users community, if this approach is feasible or if it is maybe bothering and the elements containing this attribute need to be limited.

We look forward to your feedback on the draft EAC-CPF 2.0. Any feedback to any of the proposed encodings, concepts, attributes, and elements is very welcome!