Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

<localControl> #105

Open
SJagodzinski opened this issue Jan 22, 2020 · 14 comments
Open

<localControl> #105

SJagodzinski opened this issue Jan 22, 2020 · 14 comments
Assignees
Labels
Element Example needed Tested by Schema Team Passed both the RNG and XSD schemas.

Comments

@SJagodzinski
Copy link
Contributor

SJagodzinski commented Jan 22, 2020

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. [email protected]

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
Copy link
Member

fordmadox commented Aug 9, 2020

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
Copy link
Member

fordmadox commented Aug 9, 2020

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
Copy link
Contributor

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
Copy link
Member

fordmadox commented Aug 10, 2020

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
Copy link
Member

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
Copy link
Contributor Author

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 SJagodzinski assigned fordmadox and ailie-s and unassigned SJagodzinski Oct 3, 2020
@SJagodzinski SJagodzinski added this to the Schema milestone Oct 3, 2020
@SJagodzinski
Copy link
Contributor Author

@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.

@SJagodzinski
Copy link
Contributor Author

Concering <term>, cf #21 and #61.

The element <term> is defined as mandatory and repeatable child element of singular elements to capture translations etc. The same solution is adapted for <localControl>.

@ailie-s
Copy link

ailie-s commented Oct 9, 2020

Tag Library Text:

Summary: An optional child element of <control>, used to specify any control information necessary to accommodate local practice.
May contain: (date, dateRange (0..1)), term (1..n)
May occur within: control
Attributes:
@audience - Optional (values limited to: external, internal)
@id - optional
@languageOfElement - optional
@localType - optional
@localTypeDeclarationReference - optional
@scriptOfElement - optional
@valueURI - optional
@vocabularySource - optional
@vocabularySourceURI - optional
Attribute Usage:
Use @localType if local practice requires recording the type of entry.
Description and Usage:
An element used to record and define any control information necessary to accommodate local practice, in addition to the elements otherwise made available within <control>.
The value of the entry must be given in a child <term> element and an associated date or range of dates can be given as either <date> or <dateRange>.
Availability: Optional, repeatable

@fordmadox
Copy link
Member

@ailie-s I believe that @localtype should now be optional. It's optional in EAD3 in this context, and though it was required in earlier versions of the EAC-CPF schema, the EAC Tag Library indicates that it should be optional here as well.

@karinbredenberg
Copy link
Member

Test of element localControl:
May occur within: control 0..n Ok in both schemas
May contain: (date, dateRange (0..1)), term (1..n) Ok in both schemas
@Audience - Optional (values limited to: external, internal) Ok in both schemas
@id - optional Ok in both schemas
@languageOfElement - optional Ok in both schemas
@localtype - required In both schemas optional
@localTypeDeclarationReference - optional Ok in both schemas
@scriptOfElement - optional Ok in both schemas
@valueURI - optional Ok in both schemas
@vocabularySource - optional Ok in both schemas
@vocabularySourceURI - optional Ok in both schemas

Result: attribute localType is optional in the schema following EAD3 use. @ailie-s might be missing camelCase in TL text for localType here.

@karinbredenberg karinbredenberg self-assigned this Nov 3, 2020
@karinbredenberg
Copy link
Member

@localType changed to optional means element passes.

@SJagodzinski
Copy link
Contributor Author

EAC-CPF team meeting, 6 Aug 2021:

  • keep <localControl>
  • list <localControl> on hold on the homepage

@SJagodzinski SJagodzinski removed this from the Tag Library milestone Dec 15, 2021
@SJagodzinski
Copy link
Contributor Author

Missing example is stated in the Tag Library:

No example has been provided for localControl. If you have any examples or use cases, please send them to TS-EAS.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Element Example needed Tested by Schema Team Passed both the RNG and XSD schemas.
Projects
None yet
Development

No branches or pull requests

6 participants