<localControl>

[SJagodzinski]

Local Control

• add attributes:
  @audience
@localTypeDeclarationReference
@scriptOfElement
@valueURI
@vocabularySource
@vocabularySourceURI
• review attributes:
  a) remove xml namespace
• keep name and scope

Creator of issue

1. Silke Jagodzinski
2. TS-EAS: EAC-CPF subgroup
3. silkejagodzinski@gmail.com

Related issues / documents

EAD3 Reconciliation

Additional EAD 3 attributes
@altrender - Optional
@audience - Optional (values limited to: external, internal)
@encodinganalog - Optional
@script - Optional

Context

Any additional control entry necessary to accommodate local practice.

May contain: <date> , <dateRange> , <term>
May occur within: <control>
Attributes: @localType - mandatory, @xml:id, @xml:lang - all optional
Availability: Optional, Repeatable

Solution documentation:

Rephrasing Summary, Description and Usage and Attribute usage needed

May contain: <date> , <dateRange> , <term>
May occur within: <control>
Attributes:
@audience - Optional (values limited to: external, internal)
@id - optional
@languageOfElement - optional
@localtype - required
@localTypeDeclarationReference - optional
@scriptOfElement - optional
@valueURI - optional
@vocabularySource - optional
@vocabularySourceURI - optional
Availability: Optional, repeatable

Example encoding

<control>
 <recordId>records identifier</recordId>
 <maintenanceStatus value="new"/>
 <publicationStatus value="inprocess"/>
 <maintenanceAgency> [...] </maintenanceAgency>
 <localControl audience="external" id="localContraol1" languageOfElement="en" localType="localtype" localTypeDeclarationReference="localTypeDeclaration1" scriptOfElement="lat" valueURI="conventionURI" vocabularySource="source" vocabularySourceURI="sourceURI">
  <term>term for local control</term>
  <date>date of local control</date>
 </localControl>
 <maintenanceHistory>  [...] </maintenanceHistory>
</control>

[fordmadox]

Nothing is required right now in this element aside from the @localType attribute, but shouldn't term be required? I don't understand the use case of having something like:

        <localControl localType="detailLevel">
            <date notBefore="1999"/>
        </localControl>

Or

        <localControl localType="topSecret"/>

Which would seem to me like at least term should be required. In the dataset I've acquired (~225k EAC files), there are 5,901 instances of localControl, and every single one has a term element (phew! 👍 ). Just 4 distinct values for those term elements in the whole set, as well:

• Complète
• Élémentaire
• Moyenne
• partial

None of those examples use date or dateRange.

All also use @localType (since it's required, although the tag library differs on that matter), and there are only 2 values used in the set that I have currently:

• niveau_de_detail
• detailLevel

That said, I'd also be in favor of dropping localControl altogether. Not sure if there are more detailed uses out there with date ranges and such, but if not, the usage mentioned here could all be accommodated in a single attribute. (e.g. cpfDescription/@levelOfDetail)

[fordmadox]

For the time being, I'll make both term and @localType required in the draft version of the schema, but I do not think that this section of control is worth keeping right now (unless people really do have use cases for attaching dates to these elements!). There is nothing "interoperable" about this section, and it seems overly complicated to me for only being useful in a local context. Far simpler is allowing users to implement an attribute in their own namespace wherever it makes sense. One benefit is that it does provide a single location to look for local extensions, if you are looking at the XML files one at a time, but I don't know how helpful this is since the files are machine-readable and since the semantics are defined locally.

[kerstarno]

I'm assuming that <term> isn't required in <localControl> as it to a certain extent is modelled after the singular elements, where <term> is not required either, but one could simply use a date element, <placeEntry>, <citation>, or <descriptiveNote> instead at the moment.

I'd agree that it would make sense to require <term> (though I'd also tend to require <term> with the singular elements, come to think about it), but I would not make @localType mandatory. This, for me, seems to be counterintuitive with regard to what this attribute is meant to be.

If we keep <localControl> we might want to consider highly recommending the use of @localType with it. Looking at the example values from your dataset, @fordmadox, it seems that those are referring back to the attribute @detaillevel, which existed in EAC beta:

<xs:attribute name="detaillevel">
  <xs:simpleType>
    <xs:restriction base="xs:NMTOKEN">
      <xs:enumeration value="minimal"/>
      <xs:enumeration value="partial"/>
      <xs:enumeration value="full"/>
    </xs:restriction>
  </xs:simpleType>
</xs:attribute>

Do we know, why this was removed respectively not taken up by values used with either <maintenanceStatus> or <publicationStatus>? If this really is the only use case for <localControl> it might make more sense to consider a dedicated element/attribute for the detail level of an EAS description?

[fordmadox]

Ah, nice! I didn't know that @detaillevel was part of EAC beta.

@localType is currently a requirement with localControl in the schema. I'm assuming that decision was made

A topic for the EAC team, but given all that, I'd love to see:

• localControl removed (unless there exist real-world uses that rely upon adding dates here, but I've never seen one)
• term (or whatever it's called) made a required child of those single elements.
• @detailLevel discussed as a new attribute, if there is a desire to have this option as a shared practice (which I think makes sense for EAC records), or as an option as part of the "Status" elements, as mentioned above.

The EAD3 tag library provides even more examples of localControl, e.g.

<localcontrol localtype="fileSize">
<term>8 MB</term>
</localcontrol>

<localcontrol localtype="daoFlag">
<term>true</term>
</localcontrol>

<localcontrol localtype="maxComponentID">
<term>414</term>
</localcontrol>

<localcontrol localtype="processinglevel">
<term>item</term>
</localcontrol>

Once again, though, none of those examples associate date information with one of the local "terms," and all of the examples would be better accommodated (in my opinion) via an attribute in another namespace, since they are all there, by definition, for local use.

[fordmadox]

Following up on this, I'm really not sure why it was put into "localControl" in EAC-CPF 1.0 in that case. From ISAAR-CPF:

5.4.5 Level of detail

Purpose: To indicate whether the authority record applies a minimal, partial or a full level of detail.

Rule: Indicate whether the record consists of a minimal, partial or full level of detail in accordance with relevant international and/or national guidelines and/or rules. In the absence of national guidelines or rules, minimal records are those that consist only of the four essential elements of an ISAAR(CPF) compliant authority record (see 4.8), while full records are those that convey information for all relevant ISAAR(CPF) elements of description.

Seems like that should be an attribute in EAC? Without it, it's not information that you can share in standard way. More to discuss with EAD, I suspect.

[SJagodzinski]

Even if //localControl is used in EAC-CPF only to capture the level of detail - and this seems to be the only use case so far - there are some more use cases in EAD3, see Mark comment above.

This EAC revision is also made to align EAD and EAC schemas and the usage of a shared schema or a shared //control part is considered.

For this reason, a decision to keep //localControl is supposed to be made by EAD team and this request will be handed over to EAD. So, we keep //localControl as element in EAC-CPF.

[SJagodzinski]

@ailie-s : As there are no major changes for this element and no more known use cases, I suggest to remove this element from Best Practise Guide.