Add a new attribute to <referringString> to specify the type of relation between the records described and the entity referred to in <referringString>

[kerstarno]

Creator of issue

1. Florence Clauvaud
2. TS-EAS EAD team liaison to EGAD
3. @florenceclavaud

The issue relates to

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

Suggested Solution

• Text: What about adding to the new <referringString> element an attribute to specify the kind of relation that exists between the records described and the entity that is referred to (just as we have the <relationType> element elsewhere)? This would be great for some users at least, otherwise they may be compelled to encode, out of the textual element, a minimal description of the <agent>, <place>, <function> or <subject> referred to, in addition to using <referringString>, which would be somewhat redundant. I hope I am clear.

[kerstarno]

EAD team discussed this issue during their meeting on 24 May 2024.

• There was general agreement that, if an option to encode relation type information were added to <referringString>, this should be done in the form of an attribute (as suggested) and not in form of a sub-element to <referringString>.
• Furthermore, there was agreement that, if such an attribute were added, its name will need to be distinct from existing elements such as <relationType> or <targetRole>.
• Last, there was agreement that the information to potentially be encoded falls more under the category of naming the role that the entity in <referringString> has towards the materials being described than naming the type of relation between both. This would also align with the function of @relator in EAD3 or @role in EAD 2002, which is available with the controlled access elements and thereby with one group of elements to be replaced by <referringString> in EAD 4.0.

However, in order to make a final decision it also was agreed that we would benefit from seeing an encoding example to illustrate the intended use case. @florenceclavaud will provide this ahead of the June meeting of the EAD team and this issue will then be discussed again.

[BrigitteMichel]

4ExamplesInLineTaggingCalames.docx
Attached : 4 real examples in EAD2 of in-line tagging taken from Calames the network for the cataloguing of archives and manuscripts of higher education in France

[florenceclavaud]

Thanks @BrigitteMichel! I will prepare an example from one of the ones you have attached.

[florenceclavaud]

So this is what the last example provided by @BrigitteMichel could look like, once encoded in EAD 4 (I also have translated the text into English):

<c id="Calames-20159101695047467">
                <identificationData>
                    <unitId localType="cote">EST GEOLMIN 12</unitId>
                    <unitTitle>Geologiska väggtaflor / by <referringString
                            referredEntityType="person" referredEntityRole="070"
                            normalizedReferredEntityName="Erdmann, Edvard (1840-1923)"
                            valueURI="170097242" vocabularySource="Sudoc"
                            referredEntityRelationType="https://www.ica.org/standards/RiC/ontology#isCreatorOf"
                            >Edvard Erdmann</referringString>. Poster series published in
                            <referringString referredEntityType="place"
                            referredEntityRole="lieu de production"
                            normalizedReferredEntityName="Stockholm (Suède)"
                            vocabularySource="Sudoc" valueURI="027622401"
                            >Stockholm</referringString> around 1875</unitTitle>
                    <unitDate standardDate="1875" certainty="uncertain">1875</unitDate>
                    <physDesc>6 boards</physDesc>
                </identificationData>
                <scopeContent>
                    <p>No BCM reference for this work.</p>
                    <p>Each figure is accompanied by explanatory text, in Swedish.</p>
                    <p>Here are described boards 1 to 6.</p>
                </scopeContent>
</c>

In fact I have added 4 attributes to the ones that referringString already has. The names I have used for those attributes are just suggestions of course; other, maybe better, names can probably be found.
The optional @referredEntityRole attribute would be used to store the contextual role that the named entity has (just like placeRole or agentRole elements, subelements of agent and place, or like the old @role attribute in EAD 2002 or @relator in EAD3). It could be filled with a URI when the role is taken from a publicly available vocabulary or ontology. In the example above, the ‘070’ value is taken from the authority list of ‘function codes’ of agents defined by the French National Library. See also my proposal for a 4th new attribute below, as an alternative option to store the URI of a relation type.

IMHO at least two other attributes are also missing there:

• an optional attribute to specify the type of the entity whose name is encoded in referringString. I have used @referredEntityType;
• an optional attribute to specify a normalized form of the name of the entity. In EAD 2002 there is a @normal attribute which has been removed in EAD4 (see Links to vocabularies in <controlAccess> sub-elements (and others) #13 (comment)). While such an attribute is of course not needed any more for agentName, placeName or term, since those elements are not inline ones and so a normalized form of the name can be stored in those elements, it may often be still needed when you use referringString in p or other text elements. I have used @normalizedReferredEntityName.

We could also consider adding a @referredEntityRelationType attribute, to specify the type of the relation that exists between the named entity and the records described. This attribute would play the same role as the relationType element elsewhere. It could be used there when @referredEntityRole is not enough, for example to specify a broader relation that would be defined in a vocabulary or ontology. This attribute could have ‘anyURI’ as data type. I have added this attribute to the first referringString in the example. Note that the relation type I have specified is the one that connects the named entity to the records described, just like for the role type.

[ArchivageNumeriqueSIAF]

Following the example of EAD2002, EAD4 allows two modes for indexing: in-line tagging or within dedicated elements. The juxtaposition of these two methods, corresponding to the current uses of librarians and archivists, is not without its risks, however.

The revision of EAD must ensure that interoperability between these two methods is organised, to enable aggregators (FranceArchives, ArchivePortalEurope, etc.) to reconcile the entities indexed using both approaches, to finally present them to users.

The development of new attributes should not lead to the creation of an information silo. EAD4 will have to find the right balance between developing new indexing methods for in-line tagging and maintaining overall consistency with direct reference to entities (place, agent, etc.). Too little correspondence between the two indexing methods could make part of the indexes invisible on some aggregator portals or when converting data to RDF.

[kerstarno]

Will be discussed by TS-EAS during their meeting on 12/13 August 2024 at the SAA Annual Meeting.

[BrigitteMichel]

Point of view of French libraries (universities libraries + public libraries + National Library) :

Currently, <referringString> only accepts text. However, there is a need to capture all the information necessary to identify both the implicit entity contained within <referringString> and the relationship to the described document unit. There are four possible solutions (which can be mixed):

solution 1 : Allow the use of <agent>, <place>, or <date> within <unittitle> and <p>.

But this is not the preferred logic for this version of EAD4.

solution 2 : Allow elements describing entities (<date>, <places>, <agents>, <subject>, <reference> (possible record entity)) within <referringString>.

This raises the issue of linking to entities outside of EAD or RiC.
Example: For <title>, libraries need to link to work titles (Work entity defined in the IFLA-LRM model) from EAD descriptions, especially for manuscripts or personal working versions of authors' documents predating their publication. This was previously handled by the <title> element, which has now disappeared.

solution 3 : Enrich the attributes of <referringString> to cover all possibly concerned entities, though this can be extremely cumbersome (e.g., <date> has very specific attributes like @certainty, @era, @notafter, @notbefore, @standardDate, @status).

If this approach is favored, we would need at least three additional attributes:
a) An attribute to specify the nature of the described entity, such as @targetType: agent, person, genreForm, title, place, date, etc. @localType could then be reserved for a typology of <referringString> and not the described entities.

b) An attribute to capture a normalized form of the entity, such as @Normal.

In half of the cases of inline indexing, the value previously entered in the NORMAL attribute in EAD2's inline indexing elements is now handled by the new @valueURI attribute.
However,

• for dates, the ISO standard is sufficient for unambiguous date reading,
• many French library personnel do not have the rights to directly enrich the authority file to which <referringString> should be linked, making @valueURI impossible. The instruction is to enter a normalized form in the current @Normal attribute to facilitate future alignment with the authority file.

This new attribute should be complemented with its equivalent for dates, @standardDate.

c) An attribute to specify the nature of the relationship, such as @relationType.

solution 4 : Define specific sub-elements within <referringString>, such as <targetType> to encode the nature of the entity contained within <referringString>, and <relationType> or <targetRole> to encode the nature of the relationship between the concerned document unit and the entity within <referringString> (addressed by the former @ROLE attribute).

As previously demonstrated by statistics: inline indexing is the standard practice for EAD in French libraries. Therefore, enriching the definition and usage rules of <referringString> is essential."

[florenceclavaud]

Hi @BrigitteMichel,

About your solution 3 below:

solution 3 : Enrich the attributes of <referringString> to cover all possibly concerned entities, though this can be extremely cumbersome (e.g., <date> has very specific attributes like @certainty, @era, @notafter, @notbefore, @standardDate, @status).

If this approach is favored, we would need at least three additional attributes: a) An attribute to specify the nature of the described entity, such as @targetType: agent, person, genreForm, title, place, date, etc. @localType could then be reserved for a typology of <referringString> and not the described entities.

b) An attribute to capture a normalized form of the entity, such as @Normal.

In half of the cases of inline indexing, the value previously entered in the NORMAL attribute in EAD2's inline indexing elements is now handled by the new @valueURI attribute. However,

* for dates, the ISO standard is sufficient for unambiguous date reading,

* many French library personnel do not have the rights to directly enrich the authority file to which `<referringString>` should be linked, making @valueURI impossible. The instruction is to enter a normalized form in the current @Normal attribute to facilitate future alignment with the authority file.

This new attribute should be complemented with its equivalent for dates, @standardDate.

c) An attribute to specify the nature of the relationship, such as @relationType.

This is was I suggested in my example above, using different names for the attributes, but basically it is the same.