Maintain <genreForm> as a separate element

[BrigitteMichel]

Creator of issue

1. Brigitte Michel ([email protected])
2. Abes (Agence bibliographique de l'enseignement supérieur = Bibliographic Agency of Higher Education)

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

Wanted change/feature

• Text: Removing <genreform> seems very problematic to us.

1. <genreform>, as practiced in EAD 2002 by French university libraries, is highly codified (source). There are 3 controlled values for @type, and for each TYPE value, there is a controlled list of NORMAL values: List 1: GenreformDocumentType; List 2: GenreformTechnique; List 3: GenreformGFF.
2. The concept of <genreform> is gaining international traction. The latest list mentioned above is soon to be replaced by a relationship to a new national reference framework defined within the LRM/RDA program as a "form of the work" (category of Work) (source RDA: Glossary, RDA Toolkit. It also exists in Bibframe (source).
3. The solution proposed by EAD 4.0 (<subjectHeadings>) goes against the international movement aiming to distinguish the form of the document and/or its content (letters, reports, photos, interviews) from the subject matter in the document.
4. There are several concepts in RiC that justify a distinct element: RiC: RiC-A10 Content Type and RiC-A17 Documentary Form Type, but it could also possibly concern RiC-A39 State.

Suggested Solution

• Text: Define <genreForm> (possibly <genresForms>) to occur within <archDes>, <c>, <c01> etc. or better in <identificationData>
• Attributes: audience, conventionDeclarationReference, id, languageOfElement, localType, localTypeDeclarationReference, maintenanceEventReference, scriptOfElement, sourceReference, target, valueURI, vocabularySource, vocabularySourceURI
• Plus @ricType and @ricId (see suggestion in Articulation with RiC: specific attributes #150)
• Plus @coverage (see Articulation with RiC - Extend the use of the @coverage attribute to other elements to indicate partial inheritance #146 for this specific aspect)
• Occurrence: optional, repeatable

Context

• Text: NB List 2 could become a new <physFacet> but Lists 1 and 3 are about the record resource (RiC-E01), not an instantiation (RiC-E06).

[florenceclavaud]

3. The solution proposed by EAD4 (`<subjectHeadings>`) goes against the international movement aiming to distinguish the form of the document and/or its content (letters, reports, photos, interviews) from the subject matter in the document.

I agree with this remark. The description and usage note of <subjectHeadings> in EAD 4 says: "Use to bundle topical or thematic access points that represent the contexts of the materials described."
While the state of a record (RiC-A39 State; e.g. copy, original, draft, etc.), its form (RiC-A17 Documentary form type; e.g. bull, charter, birth certificate...; and also what diplomatics calls 'nature juridique', in English 'legal nature', e.g. gift, grant, endourment...) are definitely not topics. They categorize the records described.

The name and application note of this element, that has replaced EAD 2002 <controlaccess>, reduce its scope.
IMHO this element should be renamed and/or (at least) the Tag Libray modified; or <genreform> or a replacing element should be reintroduced directly in <c> or <identificationData>.

4. There are several concepts in RiC that justify a distinct element: RiC: RiC-A10 Content Type and RiC-A17 Documentary Form Type, but it could also possibly concern RiC-A39 State.

Yes, I agree too; see my reaction above.
I would add that <genreform> was also used to categorize groups of records, not only items. So RiC-A36 Record Set Type can be added to this list of attributes.

[MicheleCombs]

I agree that retaining genreform makes sense, for all the reasons given above. It seems to me that it would be both practically damaging and semantically suspect to force the intellectual and the physical into a single element.

[kerstarno]

This will be discussed by TS-EAS during their meeting on 12/13 August 2024.

[kerstarno]

Discussed at the TS-EAS meeting on 12/13 August 2024 in the context of reviewing the approach to encoding physical description and related information in general. It was agreed to reintroduce <genreForm>.

The relevant changes will be addressed via #155.