MARC21 Breadcrumbs in LRM/RDA/RDF Output

[CECSpecialistI]

Our mapping will be lossy. We are mapping a number of MARC fields which lack the specificity needed for more granular LRM/RDA/RDF properties to broader properties, such as notes on broad entities, which could be cleaned up by humans or improved code in the future. It will be useful to those future humans and/or machines to know what the MARC tags for these triples looked like before they were transformed to LRM/RDA/RDF.

We would like to include provision for this in mapping/transform/both.

We need to establish exactly what information we would like to include, and how the data should be structured in our LRM/RDA/RDF output.

See related discussion: Reification in the mapping

Discussion from meeting 2022-06-08:

@szapoun described National Library of Greece's work on MARC21 authority data in LRM/RDA/RDF using Wikibase, use of qualifiers and internal notes to facilitate mapping back to MARC21

BIBFRAME has a note type vocabulary that could be useful.

RDA Registry --> About --> RDA for Developers

RDA Unconstrained Properties

[GordonDunsire]

For information, the LRM has examples of MARC encoding:

LRM-E1-A2 Res Note:

317 ## $a Inscription on the title page in sixteenth century hand, ‘Iohannes Wagge me iure tenet’ $5 DB/S-5-KK.555 [note on ownership history of an item as expressed in a UNIMARC field]

This is clearly a single string value of a 'note on manifestation' attribute element:

ex:M1 rdamd:P30137 "317 ## $a Inscription on the title page in sixteenth century hand, ‘Iohannes Wagge me iure tenet’ $5 DB/S-5-KK.555" .

LRM-E3-A2 Expression Extent:

306 ## ‡a 002052 ‡a 000415 ‡a 000956 ‡a 003406 [durations encoded in a MARC 21 field]

ex:E1 rdaed:P20321 "306 ## ‡a 002052 ‡a 000415 ‡a 000956 ‡a 003406" .

LRM-E3-A5 Expression Cartographic scale:

034 1# ‡a a ‡b 100000 [cartographic scale expressed in normalized form in a MARC 21 field]

ex:E2 rdaed:P20228 "034 1# ‡a a ‡b 100000" .

LRM-E3-A8 Expression Medium of performance:

382 0# ‡a trumpet ‡n 2 ‡a trombone ‡n 2 ‡s 4 [medium of performance expressed in a MARC 21 field]

ex:E4 rdae:P20215 "382 0# ‡a trumpet ‡n 2 ‡a trombone ‡n 2 ‡s 4" .

LRM-E4-A2 Manifestation Extent:

300 ## $a 301 p., [8] p. of plates [number of pages, recorded according to AACR2 and expressed in a MARC 21 subfield]

ex:M2 rdamd:P30182 "300 ## $a 301 p., [8] p. of plates" .

LRM-E4-A5 Manifestation Access conditions:

538 ## ‡a System requirements: IBM 360 and 370; 9K bytes of internal memory; OS SVS and OSMVS. [system requirements expressed in a MARC 21 field]

538 ## ‡a Blu-ray 3D: requires Blu-ray player; 3D version requirements: full HD TV, compatible 3D glasses, Blu-ray 3D Player or PS3, and high speed HDMI cable. [system requirements for a video disc expressed in a MARC 21 field]

538 ## ‡a PSP (PlayStation portable); region 1; wi-fi compatible. [system requirements for a video game expressed in a MARC 21 field]

ex:M3 rdamd:P30145 "538 ## ‡a System requirements: IBM 360 and 370; 9K bytes of internal memory; OS SVS and OSMVS." .

ex:M4 rdamd:P30145 "538 ## ‡a Blu-ray 3D: requires Blu-ray player; 3D version requirements: full HD TV, compatible 3D glasses, Blu-ray 3D Player or PS3, and high speed HDMI cable." .

ex:M5 rdamd:P30145 "538 ## ‡a PSP (PlayStation portable); region 1; wi-fi compatible." .

{These are the only examples; I guess the editors were in a rush to meet deadlines.]

I can see one issue: These strings would normally be treated as RDA structured descriptions, with MARC 21 Bibliographic as the string encoding scheme. But the RDA note elements can only treat them as unstructured descriptions, so there is a problem with the first example.

However, this makes no different to the RDA/RDF: all strings are datatype values. The main difference is in data provenance: a structured description has an option to add an SES as data provenance, but an unstructured description does not. This does not prevent provenance for an SES being given for an unstructured note value; it's just unexpected. Expectations can be managed with documentation.

Another issue is granularity. How is a specific subfield and its contents represented? The LRM has a UNIMARC example that includes a mark of omission, but I'm not sure it's valid or crumbable. I guess that could be allowed with appropriate documentation, assuming MARC 21 has not yet appropriated ... as a subfield code ;-) After the transformation it's just a (structured) RDA string that may or may not be parseable, depending on the SES that was used.

[GordonDunsire]

Further thoughts:

The issue of recording a structured encoded string as an unstructured note can be resolved by declaring a "transform" element subtype of the general note datatype element (of each of Work, Expression, and Manifestation). For Manifestation:

transformDomain:MCrumb rdfs:subPropertyOf rdamd:P30137 .

ex:M1 transformDomain:MCrumb "500 ##$aRecast in bronze from artist's plaster original of 1903." .
ex:M1 rdamd:P30137 "Recast in bronze from artist's plaster original of 1903." .

ex:M2 transformDomain:MCrumb "521 3#$aTactile learner$adiscalculia$bCenter for Disabilities." .
ex:M1 rdamd:P30137 "Tactile learner; discalculia (source: Center for Disabilities). " . // Encoding replaced by boilerplate

This does not prevent the treatment of the value of transformDomain:MCrumb as a structured string in a "transformed data" application. For a broader RDA application, however, the structured string is "dumbed-up" as an unstructured note, or more probably simply ignored because the result is only good for display to a cataloguer (not an end-user) and produces unwanted results if keyword indexed, for example "##$aRecast" and "learner$adiscalculia$bCenter".

This approach can be applied to all descriptive/annotation tags:

ex:M3 transformDomain:MCrumb "245 04$aThe plays of Oscar Wilde /$cAlan Bird." .
ex:M3 rdamd:P30137 "The plays of Oscar Wilde / Alan Bird." // encoding removed for embedded punctuation
ex:M3 rdamd:P30156 "The plays of Oscar Wilde" .

This also resolves the issue with using marks of omission.

To generalize, all descriptive annotation tags might be output as a breadcrumb block:

ex:M3 transformDomain:MCrumb "245 ..." .
ex:M3 transformDomain:MCrumb "247 ..." .
ex:M3 transformDomain:MCrumb "250 ..." .
ex:M3 transformDomain:MCrumb "260 ..." .
[etc.]

This can be generated independently of the transform itself.

It is really the equivalent of outputting the whole source record as a structured string, and the block can be reduced to a single statement:

ex:M3 transformDomain:MCrumb "245 ... 247 ... 250 ... 260 ..." .

The true breadcrumb here is the subject IRI for the 'whole' manifestation that is described by the record.

[tmqdeborah]

I went looking for previous discussions on these topics and found these:

• Creating identifiers #375; example of “fake:marcfieldF020” in “Creating identifiers”
• MARC21 Breadcrumbs in LRM/RDA/RDF Output #367; re. MARC21 Breadcrumbs

The MARC21 Breadcrumbs seemed the most comprehensive, so I am using it to share my suggestions for the discussion today.

Domain: Manifestation IRI

• To see MARC data for Work and Expression elements, users will need to get to the Manifestation description.

Relationship: manifestation described with metadata by

• The Recording guidance for this element says to “Record a structured description for a related work as a value of Work: access point for work”. So, that would have to mean that an entire MARC record can be considered a structured description that is a nomen.

Range:

• Literal string: in ... format:
  o Raw MARC might not be a good choice for an average user as it contains non-printing characters, plus the directory, which isn’t needed, and needs a separate application to make it readable, e.g., for referring to the record for cleanup purposes
  o MARCXML would be the most universal and is readable without a separate application, but can also be opened by a separate application to make it more readable
• Or Nomen IRI; so that we can add provenance elements, e.g.:
  o Nomen: nomen string: <[entire MARC record in ... format]> --structured description
  o Nomen: scheme of nomen: MARC21 Bibliographic Format --structured description
  o Nomen: language of nomen: from 040$b –VES IRI
  Etc.

[GordonDunsire]

I think we need to resolve this asap, so that we can stop using the fake:marcfield statements in the test output and also see what a beta version of the transform looks like.

@tmqdeborah: this approach doesn't work because the 'thing in itself' cannot be its own appellation (because that would make it a nomen, not a metadata work/expression/manifestation.

We are comfortably using a methodology for accommodating identifiers with sources as nomens, which has been alpha tested. So we can update a general model:

Notes:

The two literals for each nomen are the nomen string and scheme of nomen.

The use of a work group nomen for the record control number and identifier (i.e. scheme) of the metadata work accommodates all variations in the actual aggregated expressions (metadata statements) that exist in variations of the MARC record (e.g. the OCLC version, a local version, etc.). The same identifier is used for all such variants.

The actual variant that is transformed is given a local identifier/IRI by the transform; this distinguishes the output for the 'same' record held in different catalogues that are transformed. The transform is given as the source of the identifier/IRI.

This provides the shortest chain of links between an entity generated by the transform and the manifestation of the MARC record, which is an online resource. Other attributes such as encoding format can specify whether the record is in MARCXML or exchange format.

There is no obvious element to accommodate the contents of the record. I considered 'has manifestation statement', but that bends the semantics more than 'has note on manifestation', which is used for contents notes.

The same instances of the metadata WEM and its nomen identifiers can be re-used for each instance of an entity minted by the transform, including agents, places, and timespans as well as the resource WEMIs. That is, the source record used by the transform is the same.

I haven't checked if there is already a mapping for 001 and 003, but they should not be used as resource WEMI identifiers, use fields 010, 016, or 035 instead.

What does everyone think about this?

[GordonDunsire]

Note also that I would expect the whole sub-graph and 'is {entity} described with metadata by' property to be suppressed in end-user displays; the data is intended for users of the transform.