Revision Notes

EAC-CPF 2.0 is the result of a major overhaul of EAC-CPF 2010 edition 2018 and incorporates new features to harmonize and reconcile the standard with EAD. Below is a summary of changes reflected in EAC-CPF 2.0.

Following ISAAR(CPF), the established structure of the control area, identity area, description area, and relations is still available, as is the idea of encoding multiple identities in one EAC-CPF instance.

The ICA Expert Group on Archival Description (ICA EGAD) is working on a 2nd draft of Records in Contexts (RiC), which is being designed as the next comprehensive description standard for archives. EAC-CPF 2.0 includes the ideas of RiC where feasible, to achieve greater interoperability.

Version control

The EAC-CPF schema was first released in 2004 as a beta version, fully released in 2010 and updated in 2018. Neither of these schemas got a proper name or version numbering. In order to differentiate and track minor and major releases of EAC-CPF a semantic versioning scheme will be applied and the new version is going to be EAC-CPF 2.0.

EAC-CPF 2.0 is a major version that will not be backwards compatible. A new minor version with added functionality in a backwards compatible manner will become EAC-CPF 2.1 and a patch version with backwards compatible bug fixes will become EAC-CPF 2.0.1 resp. EAC-CPF 2.1.1 etc.

Spelling

The question of spelling was widely discussed since the related standard, EAD, uses lower-case for element and attribute names. For easier reading and teaching it was agreed to keep the camel case spelling for element and attribute names and also for fixed values.

List of removed, renamed or replaced and added elements and attributes

The list summarizes the changes for elements and attributes each in alphabetical order. Following elements were removed without substitution:

<level>
<objectBinWrap>
<outline>

Following elements were renamed or replaced to be more precise or to align with EAD:

<abbreviation> renamed to <shortCode>
<agentType> replaced by <agent @agentType>
<alternativeForm> replaced by <nameEntry @status="alternative">
<authorizedForm> replaced by <nameEntry @status="authorized">
<citation> renamed to <reference>
<cpfRelation> replaced by <targetEntity @targetType="person" or "family" or "corporateBody" or"agent">
<eac-cpf> renamed to <eac>
<entityId> renamed to <identityId>
<eventType> replaced by <maintenanceEvent @maintenanceEventType>
<functionRelation> replaced by <targetEntity @targetType="function">
<maintenanceStatus> replaced by <control @maintenanceStatus>
<nameEntryParallel> renamed to <nameEntrySet>
<placeEntry> renamed to <placeName>
<preferredForm> replaced by <nameEntry @preferredForm>
<publicationStatus> replaced by <control @publicationStatus>
<relationEntry> replaced by <targetEntity>
<resourceRelation> replaced by <targetEntity @targetType="resource">
<script> renamed to <writingSystem>
<sourceEntry> replaced by <reference>

Following elements were added:

<chronItem>
<chronItemSet>
<citedRange>
<contact>
<contactLine>
<geographicCoordinates>
<head>
<relation>
<relationType>
<representation>
<targetEntity>
<targetRole>

Following attributes were removed without substitution:

@accuracy
@altitude
@lastDateTimeVerified
@latitude
@longitude
@transliteration
@xlink:actuate
@xlink:arcrole
@xlink:show

Following attributes were renamed/replaced:

@scriptCode renamed to @scriptOfElement
@xlink:href replaced by @href
@xlink:linkrole replaced by @linkRole
@xlink:linktitle replaced by @linkTitle
@xml:base replaced by @base
@xml:id replaced by @id
@xml:lang replaced by @languageOfElement

Following attributes were added:

@agentType
@audience
@calendar
@certainty
@contactLineType
@conventionDeclarationReference
@coordinateSystem
@countryEncoding
@dateEncoding
@detailLevel
@era
@languageEncoding
@listType
@localTypeDeclarationReference
@maintenanceEventReference
@maintenanceEventType
@maintenanceStatus
@preferredForm
@publicationStatus
@repositoryEncoding
@scriptEncoding
@sourceReference
@status
@target
@targetType
@unit
@value
@vocabularySourceURI
@vocabularyURI

Simplified schema

To support and facilitate EAC-CPF schema usage a few general principles have been defined:

Elements

Elements are ordered within their parent elements as follows:

required, not repeatable elements
required, repeatable elements
optional, not repeatable elements
optional repeatable elements

Following the communities feedback from 2012 to harmonize the role and function of singular and plural elements, the current EAC-CPF schema has two concepts to bundle elements:

Plural elements

Plural elements serve as wrapper elements for one or more singular elements of the same kind. Examples include <functions>, <legalStatuses>, and <mandates>.

Plural elements can occur once, all are optional and not repeatable, and they must contain at least one singular element, but can include unlimited additional singular elements, plus a descriptive note. A new singular element within its plural wrapper is needed for a new entry. Translations can be given in a repeated term of the singular element.

Even a single singular element needs to be wrapped by a plural element.

Element sets

Element sets bundle elements with different concepts/information. Examples include <dateSet> and <chronItemSet>.

Attributes

Next to specified EAC-CPF attributes, all elements can contain any additional attributes from any other namespace.

There are three global attributes for all elements:

@id to refer to the element,
@target to point to another element within the EAC-CPF instance (not available in <eac>),
@audience to control the visibility of an element.

The attribute @status is introduced to elements for identifiers, codes, names, and dates to add status information on their validity.

Relaxed data type and elements definition

Restrictions on element content and attribute values were relaxed for the following cases:

<recordId> relaxed from NMTOKEN to text (must have at least one non-whitespace character)
<agencyCode> relaxed the constraint ISO 15511 to text
@countryCode, @languageCode, @scriptCode relaxed the constraint ISO standards (ISO 3166-1, ISO 639-2, ISO 15924) to NMTOKEN
@localType data type relaxed from anyURI to token
@vocabularySource data type relaxed from NMTOKEN to token.

Schema alignment with EAD

TS-EAS is responsible for maintaining two archival encoding standards: EAD and EAC-CPF. The user communities of both standards overlap; therefore, the alignment of both schemas, where possible, shall ease the standards’ maintenance, usage, teaching, and learning.

Elements

To harmonize the control area of both standards, EAC-CPF contains the following changes:

The element <control> contains new optional attributes for external encoding standards: @countryEncoding, @dateEncoding, @languageEncoding, @repositoryEncoding, and @scriptEncoding.
The element <representation> is introduced as an optional child element of <control>.
The element <geographicCoordinates> is introduced as an optional child element of <place>.
The element <chronItemSet> is introduced as an optional child element of <chronItem> to bind several events and places to a date.

Attributes

Changes to attributes resulting from the EAD3 realignment, with some attributes borrowed from EAD and introduced in EAC-CPF 2.0, include:

Removed XML namespace
- @xml:id becomes optional attribute @id that is available for all elements
- @xml:lang becomes optional attribute @languageOfElement and is available for non-empty elements, i.e., the element can contain text directly or via its child elements
- @xml:base becomes optional attribute @base
Removed XLink namespace
- @xlink:actuate, @xlink:arcrole, and @xlink:show were removed
- @xlink:linkrole, @xlink:linktitle, and @xlink:href become optional attributes under the new names @linkRole, @linkTitle, and @href, respectively
Newly added attributes borrowed from EAD
- @audience as a global optional attribute for all elements with the values: external, internal
- @calendar, @certainty, and @era as optional attributes for date elements, cf. date encoding
- @coordinateSystem as a required attribute in to enter the code for a system used to express geographic coordinates, cf. place encoding
- @listType as an optional attribute in to specify the type of a list with the values: ordered, unordered
- @unit as an optional attribute in the new element , cf. assertion description
- @value as a required attribute in with the values: corporateBody, person, family, c.f. identity area

Modified encoding

With the goal of simplifying the schema and aligning it with EAD, some encoding concepts were modified. For linking internally within an EAC-CPF instance and referencing externally to other sources, coherent basics have been defined. Also formatting options were cleared up and emphasizes the usage of W3C CSS values.

Linking and referencing

The EAC-CPF schema now provides possibilities to link internally to any other element within the same EAC-CPF instance and externally to any other online resource.

Internal linking between the EAC-CPF elements can be realized with the global optional attribute @id to tag an element uniquely. The new global optional attribute @target can then be used to point to any element with an attribute @id. Furthermore, there are four attributes to link directly to declarations of rules and conventions, local type definitions, maintenance events, and sources. These specific reference attributes (@conventionDeclarationReference, @localTypeDeclarationReference, @maintenanceEventReference, and @sourceReference) are optionally available in all elements in the identity area, except in <entityType>, in the description area, and in the relations. All attributes for internal linking are defined with data type IDREFS to provide multiple link targets, if necessary.

To support interoperability with linked data next to the existing attribute @vocabularySource, two new linking attributes, @vocabularyURI and @vocabularySourceURI, were added. They serve as optional attributes in all elements that can contain any type of entity (e.g., the attributes are available in elements encoding identifiers like <otherRecordId>, <otherAgencyCode>, and <identityId>). They are also available in the elements <event>, <function>, <legalStatus>, <localControl>, <localDescription>, <mandate>, <nameEntry>, <occupation>, <otherEntityType>, <place>, <placeName>, <relationType>, and <targetRole> where links to vocabularies, thesauri, or authority files might be useful.

When creating links to external generic resources (like any website, preferably with a persistent URI) the element <reference>, formerly known as <citation>, with the optional attribute @href should be used. The element <reference @href> is available in a wide range of EAC-CPF elements as a child element of <p>. If there is not a <descriptiveNote> with <p> available, the element <reference> is added. The optional attributes @linkRole, and @linkTitle accompany @href. The attribute @lastDateTimeVerified next to @href was removed as it is underused and it seems a relic of early internet days.

To clarify, if a link to a Wikipedia page is provided, use the element <reference @href>, but if a reference to a Wikidata ID shall be given, use @vocabularyURI.

Formatting

Generally, EAC-CPF does not provide any formatting possibilities. However, as EAC-CPF is an encoding standard for archival descriptions (which may comprise narrative text), some formatting options are needed to assist readers with easily ascertaining the text.

The element <span>, as a child element of some text elements (<abstract>, <event>, <eventDescription>, <head>, <item>, <reference>, <p>) with the optional attribute @style, is used to format words or phrases for linguistic effect. Values of the attribute @style should conform to W3C CSS.

Lists can be formatted as an ordered or an unordered list, specified in the optional attribute @listType, with the attribute @style and a W3C CSS value.

Along with <list>, elements designed to include descriptive text such as <biogHist>, <generalContext>, and <structureOrGenealogy> can contain the new element <head> to encode a title or caption for a section of text.

Updated content models

Community feedback between 2010 and 2018 included issues about cloudy descriptions in the Tag Library as well as ambiguous solutions to use the provided elements and attributes for encoding. Therefore the content model for the encoding of dates, languages, entity types, names, places, lists, and relations is updated. The encoding for descriptions of assertions and demographic information is newly introduced.

Date encoding

Date encoding is possible for single dates (<date>), for time spans (<dateRange> with child elements <fromDate> and <toDate>), and for complex dates (<dateSet> with child elements <date> and <dateRange>). This concept was introduced with EAD many years ago; it is well established and did not change for EAC-CPF 2.0.

All text date elements (<date>, <fromDate>, <toDate>) can contain the new optional attributes @calendar and @era to specify the date being encoded and to be aligned with EAD.

The users community asked for best practise to encode uncertain and unknown dates. So, the elements <date>, <fromDate> and <toDate> may also include the new optional attribute @status to indicate unknown or open dates, using the values unknown or ongoing. The optional attribute @certainty can be used to indicate the level of confidence for the information given in <date>, <fromDate>, or <toDate> (e.g., approximate or circa).

Additionally, the usage of Extended Date/Time Format (EDTF) integrated in ISO 8601‐2019, to qualify a date as uncertain (?), approximate (~), or uncertain and approximate (%), is possible via the optional attribute @standardDate.

Language encoding

Language information can be given in several places of an EAC-CPF instance depending on the context and the object of the attributed language.

Encoding standards

First, the encoding standard for the representation of a language name and script needs to be specified in <control> using the new optional attributes @languageEncoding and @scriptEncoding (e.g., iso639-1 or iso15924). All language and script codes specified in one EAC-CPF instance should follow the same standard.

This approach follows EAD and introduces the specification for the language and script codes. Besides, the issue of different language code recommendations in EAC-CPF 2010 is solved with this solution. As for EAD, EAC-CPF does not recommend the usage of a specific list of short codes for language names but facilitates the use of international standards like ISO 639 code sets and any other language and script code, defined in <conventionDeclaration>. Additionally, EAC-CPF 2.0 explicitly proposes the usage of IETF language tags often used by computing standards.

In the call for comments, a question for usage of IETF language tags was addressed to the community, but did not gain any feedback so far.

Language used in the EAC-CPF instance

Second, the language and script codes themselves might be entered in the attributes @languageCode and @scriptCode, following the once declared encoding standard. This approach did not change with EAC-CPF 2.0. The attribute @languageCode is required to be used within the element <languageDeclaration> as a child element of <control>; whereas, @scriptCode is an optional attribute of this element. Due to simplifying the schema, <languageDeclaration> now declares the language and script in which an EAC-CPF instance is written with both attributes and it cannot contain any text, but can have a descriptive note.

The language and the writing system of the content of each single text element can be specified by using the optional attributes @languageOfElement and @scriptOfElement. Both elements contain the language and script codes, following the once declared encoding standard. To achieve greater distinction, the attributes @xml:lang and @scriptCode were renamed.

This new approach enables users to create multilingual EAC-CPF descriptions. Languages and scripts for elements’ content might be specified in an element or in the parent or wrapper element to summarize language and script information for an encoding section. Most text elements in the description area are repeatable for translation.

While it is possible to specify the language and the writing system for each single element, it might be more feasible to encode the primary language in the EAC-CPF instance in <languageDeclaration>. Use the single element language attribute @languageOfElement only in cases where the content language differs from the primary language.

Language used in the creative work of an CPF entity

Third, the attribute @languageCode is also available as an optional attribute in the element <language>, a child element of <languageUsed>. The element <language> identifies a particular language used in the creative work of the CPF entity being described and can contain the name of the language itself, next to the attribute @languageCode using the code for said language.

In the same sense, the optional attribute @scriptCode is available in the element <writingSystem>, formerly known as <script>, also a child element of <languageUsed>. The element <writingSystem> identifies the writing script for a language in which the CPF entity being described was creative or productive. The element <writingSystem> can contain the name of the script, whereas the attribute @scriptCode uses the code for said script.

Transliteration

The attribute @transliteration was removed from EAC-CPF 2.0 in the process of clearing up unused or redundant components.

In order to specify the system, conventions, or rules applied to transliteration, the element <conventionDeclaration> in <control> should be used. The optional attribute @conventionDeclarationReference can be used to refer to the according convention declaration for the transliteration scheme. The optional attribute @conventionDeclaratio

Control area

The control area is mainly updated for EAD alignment and to simplify the schema.

Transformed elements

Upon evaluation of the elements and attributes, some elements were removed and superseded by attributes in their parent elements in EAC-CPF 2.0.

Elements to encode status information on an EAC-CPF instance:

<maintenanceStatus> becomes the mandatory attribute @maintenanceStatus in <control> with the values: revised, deleted, new, deletedSplit, deletedMerged, deletedReplaced, cancelled, derived
<publicationStatus> becomes the optional attribute @publicationStatus in <control> with the values: approved, inProcess, published
<localControl localType="detailLevel"> with child element <term>minimal</term> becomes the optional attribute @detailLevel in <control> with the values: minimal, basic, extended

Elements with type information:

<eventType> becomes the mandatory attribute @maintenanceEventType in <maintenanceEvent> with the values: cancelled, created, deleted, derived, revised, unknown, updated
<agentType> becomes the mandatory attribute @agentType in <agent> with the values: human, machine, unknown

Emphasized elements

The convention declaration in control will be used to provide rules for transliteration and rules for authorized, alternative, and preferred forms of names, cf. name encoding and language encoding. A new optional attribute @conventionDeclarationReference in the elements of the identity area, the description area, and the relations allows for linking to a specific convention declaration (i.e., to <conventionDeclaration @id> in the current EAC-CPF instance).

Information given in the elements <source> and <maintenanceEvent> lay the foundation to the description of an assertion to the EAC-CPF description, cf. assertion description. The new optional attributes @sourceReference and @maintenanceEventRefercence in the elements of the description area allow for linking to a specific source and maintenance event (i.e., to <source @id> or <maintenanceEvent @id> in the current EAC-CPF instance).

The optional attribute @localType is still used to support an element semantically. The specification of values available in @localType is given in the <localTypeDeclaration>. The new optional attribute @localTypeDeclarationReference accompanies each attribute @localType and allows for linking to a specific local type declaration (i.e., to <localTypeDeclaration @id> in the current EAC-CPF instance).

Identity area

The identity area has changed slightly.

Due to RiC-CMs new concept of advanced agent entities, it is now possible to encode additional entity types complementary to the given options person, family, and corporate body. Next to the mandatory element <entityType> (now designed as an empty element with the mandatory attribute @value, values: person, family, corporateBody) a new optional element (<otherEntityTypes>) provides the option to enter one or more entity types as text information or as reference to a vocabulary.

Inspired by community feedback the element <entityId> was renamed to <identityId> to be more precise .

The wrapper element <nameEntryParallel> was renamed to <nameEntrySet>, cf. name encoding and Elements.

Name encoding

Encoding various forms of names is essential for EAC-CPF producers. There are different reasons that make it necessary to encode several names for one entity. According to community feedback, the control of names, i.e. authorized, alternative and preferred names, was confusing in EAC-CPF 2010.

Rename the grouping element

The grouping element for names is renamed from <nameEntryParallel> to <nameEntrySet>. A name entry set can contain one or more name entries and dates. It can record parallel names that have equal statuses of being authorized and it can also encode multiple name forms, including translations of a name or an abbreviation.

Status of a name

The quality of a name, authorized or alternative form, can now be given with the new optional attribute @status (values: authorized, alternative) in each element <nameEntry>.

Rules or conventions to express the name can be defined in <conventionDeclaration> in the control area; the same applies to any rule or convention according to which the name is the authorized or alternative form. The optional attribute @conventionDeclarationReference in <nameEntry> points directly to the according convention declaration (i.e., to <conventionDeclaration @id>).

The optional attribute @preferredForm (values: true, false) supersedes the element <preferredForm> and specifies whether or not a name entry provides the preferred form of a name for display. A convention declaration can be used to define the rules or conventions according to which a name is deemed as preferred to others.

Translations and parallel names

The optional attribute @localType (value: parallel) in <nameEntrySet> should be used to reflect the usage of parallel names.

The same optional attribute @localType in <nameEntry> should be used to indicate what kind of parallel name is used (e.g., translation).

The attended optional attribute @localTypeDeclarationReference points directly to the according local type declaration (i.e., to <localTypeDeclaration @id>).

Description area

The description area keeps all descriptive information according to ISAAR(CPF) but changes the encoding of plural elements, cf. Elements. Two new description aspects were added due to users requests: description of assertions and descriptions of demographic information.

Place encoding

Places are, along with names and dates, paramount when describing archival context. A place can be given to locate a function, a legal status, a local description, a mandate, an occupation, and any other entity types, but also to describe a biography or history and to locate a relation. Of course, the element <places> still serves as a plural element to include one or more elements <place> to describe any place connected with the entity described.

The element <placeEntry> is renamed to <placeName> to be more precise. The optional attribute @accuracy was removed since there was not a single use case available.

The element <place> has two new child elements. Next to the existing optional element <address> as a wrapper element for any physical or analog address information, the new optional element <contact> allows for bundling digital addresses and contact information. Both follow the same content model of at least one or more address lines or contact lines. The <address> element is ideally bound with a place name. The other new optional child element of <place> is <geographicCoordinates>. Following EAD encoding, the element <geographicCoordinates> is used to express a set of geographic coordinates as text. The mandatory attribute @coordinateSystem specifies the system used to express the geographic coordinates. In this context, the optional attributes @altitude, @latitude, and @longitude are removed.

The encoding of lists was revised and simplified in EAC-CPF 2.0. An element <list> can contain the new optional element <head>, the optional element <item>, and the optional element <list>. This results in a new way of nesting lists to express hierarchies or family trees, which replaces the use of the element <outline> with <level> that has been removed.

List encoding

The encoding of lists was revised and simplified in EAC-CPF 2.0.

An element <list> can contain the new optional element <head>, the optional element <item>, and the optional element <list>. This results in a new way of nesting lists to express hierarchies or family trees, which replaces the use of the element <outline> with <level> that has been removed.

The optional attribute @listType, with the values ordered and unordered, specifies the type of a list and the optional attribute @style can be used to define the style of the list type with W3C CSS values.

Assertion description

The EAC-CPF user community has long desired the ability to add evidence-based assertions. With EAC-CPF 2.0, it is possible to enter new information with a range of existing elements in the control area. Additionally, all information in the description area is repeatable in order to add assertions there as well, as desired.

To provide additional, differing, or new information, the corresponding element in the description area must be repeated with the new information entry.

The source supporting the information can be given in the control area in the repeatable element <source>. Here, the new optional element <citedRange> with the optional attribute @unit (no limited values) can contain detailed information like page number(s), paragraphs, or editions, in order to give detailed evidence to a source. Next to <citedRange>, the element <source> can contain <descriptiveNote>, <objectXMLWrap>, and <reference>. The optional attribute @sourceReference in the elements in the description area links directly to the according element <source> (i.e., to <source @id>).

The agent responsible for adding an assertion and the date when an assertion was added or revised has to be entered in <maintenanceEvent> in the control area. A <maintenanceEvent> can be described with <agent>, <eventDateTime>, and <eventDescription>. The optional attribute @maintenanceEventReference in the elements in the description area links directly to the corresponding element <maintenanceEvent> (i.e., to <maintenanceEvent @id>).

A rule used for formulating the assertion can be added in <conventionDeclaration> in the control area. The optional attribute @conventionDeclarationReference in the elements in the description area links directly to the according convention declaration (i.e., to <conventionDeclaration @id>).

Demographic description

One of the community feedback on the call for comments affects distinct descriptive information on persons. EAC-CPF 2010 recommends the usage of <localDescription> “[…] to extend the descriptive categories to others available in a local system. Its meaning will depend on the context in which it occurs.”¹ In practice, any information about gender, citizenship, or religion of an entity would be encoded in this generic and semantically weak element.

To be more precise and distinct the new element <demographicDescription> is introduced in EAC-CPF 2.0 to provide this kind of demographic information on entities. Depending on archival description culture and tradition, data privacy and legal rules of the maintenance agency, any kind of demographic information might be added now.

Relations

Relations got a new encoding structure in order to simplify them and to achieve better interoperability.

The optional element <relations> still serves as a wrapper element for one or more single relation entries.

Each element <relation> contains one required element <targetEntity> to identify the entity that is being targeted by the relation. The mandatory attribute @targetType specifies the type of the entity as an agent, a corporate body, a person, a family, a resource, or a function, whereas the attribute value agent is foreseen mainly for conversion from EAC-CPF 2010 to EAC-CPF 2.0. The targeted entity can be encoded with URIs and references to an authority record or any other external file using the optional attributes @vocabularySource, @vocabularyURI, and @vocabularySourceURI.

The optional element <relationType> within <relation> specifies the type of relation that the entity being described within the EAC-CPF instance has to the targeted entity. Relation types are not fixed and can be given as identity, hierarchical, temporal, family, or associative, but also as creator or subject of a resource. Relations between the entity being described and a function could be controls, owns, or performs. The relation type is given as element text content and also allows using the optional attributes @vocabularySource, @vocabularyURI, and @vocabularySourceURI.

A third target element is called <targetRole> and can be used to provide information about the role of the targeted entity toward the entity described. Family roles like parent, child, or sibling can be given in that text element.

Furthermore, relation context can be given with date, place, and descriptive information in the according child elements of <relation>: <date>, <dateRange>, <dateSet>, <descriptiveNote>, <objectXMLWrap>, and <place>.

Pending issues

During the revision on each single element the usage of only one element is uncertain and pending. The only use case for the element <localControl> in EAC-CPF 2010 is the encoding of the level of detail according to ISAAR(CPF) 5.4.5.² In the sense of simplifying the schema and clearing up unused components, this element seems to be better transformed into an attribute @detailLevel within <control> with limited values.

The element <localControl> is a shared element with EAD3. The decision of keeping or removing <localControl> from EAS schemas was handed over to the TS-EAS EAD subteam to discuss use cases, usage and gathering community feedback during the upcoming EAD3 revision process. The next EAC-CPF revision will follow the decision for EAD. The element <localControl> is marked as on hold in the EAC-CPF documentation.

EAC-CPF Tag Library Version 2010 Revised Edition 2018. Prepared and maintained by the Technical Subcommittee for Encoded Archival Context of the Society of American Archivists and the Staatsbibliothek zu Berlin. ↩
ISAAR(CPF), 2nd ed., 2004. p. 27. ↩