Current situation or problem:

In scope

Augment transformation pipeline with the Library of Congress' BIBFRAME 2.0 model

(See : https://www.loc.gov/bibframe/docs/bibframe2-model.html)

• Update the transformation rules to reflect the mapping and conversion requirements specified in the LC's BIBFRAME 2.0 model.

• Ensure the transformation of MARC records adhere to the specific BIBFRAME model version indicated by LC (as well as MADS RDF and the BF extension).

1xx MARC Fields

• Develop rules to map and transform the 1xx fields (main entry) of bibliographic records to appropriate BIBFRAME properties.

• Handle variations in 1xx fields across different MARC formats (e.g., MARC21, UNIMARC, etc.).

• Validate the transformed properties against the BIBFRAME model and LC specifications.

2xx MARC Fields

• Define rules to map and transform the 2xx fields (title and statement of responsibility) of bibliographic records to appropriate BIBFRAME properties.

• Handle multiple subfields, indicators, and formatting variations present in 2xx fields.

• Ensure the transformed properties comply with the BIBFRAME model and LC requirements.

3xx MARC Fields

• Implement rules for mapping and transforming the 3xx fields (physical description, etc.) of bibliographic records to corresponding BIBFRAME properties.

• Handle different subfields and indicators associated with 3xx fields.

• Validate the transformed properties against the BIBFRAME model and LC guidelines.

Additionally, the library will expect the ability to configure / edit / change settings to the transformation rules to stay current with the MARC standard. That is, the library would want to make the changes directly through the module, and not be dependent on submitting a ticket for processing the request. 

Out of scope

Use case(s)

Proposed solution/stories

Links to additional info

Questions

• Discuss range of scope for this feature around remaining MARC tags (e.g. control fields, 4xx, 5xx . . . 9xx) - can the feature cover building a pipeline that covers MARC records completely, or should we break it up into two or more features?

• Are there any additional MARC fields or subfields that need to be considered for transformation that aren’t already included in the rules? (besides 9xx)

• Should the rule building user interface be integrated into an existing system or developed as a standalone application?

• Do we need to transform ONIX?