Dear Colleagues,

here are the comments from the Expertengruppe Datenformate (Committee on Data Formats, for libraries in German speaking countries) on the papers of the MARC Advisory Committee meetings during ALA Midwinter 2016.

Proposal 2016-01:
Coding 007 Field Positions for Digital Reproductions of Sound Recordings in the MARC 21 Bibliographic Format
http://www.loc.gov/marc/mac/2016/2016-01.html 

We support this paper.

Proposal 2016-02:
Defining Subfield $r and Subfield $t, and Redefining Subfield $e in Field 382 of the MARC 21 Bibliographic and Authority Formats
http://www.loc.gov/marc/mac/2016/2016-02.html 

In general, we support this paper.  We will continue our practice to repeat 382 for each new medium of performance, so that links via $0's can be provided.  In combination with 2016-DP01, field 382 seems to become more complicated than before.  Hopefully the data will be created in a consistent way, so that services can offer what (end) users are looking for.

Discussion Paper 2016-DP01:
Defining Subfields $3 and $5 in Field 382 of the MARC 21 Bibliographic Format
http://www.loc.gov/marc/mac/2016/2016-dp01.html 

The scenarios described in this paper are understandable.  However the usage of $3's for compilations does not seem to solve the issue.  We would strongly prefer a solution with $8's instead, linking together two or more fields inside the same record.  We can imagine an analytic approach (creating single records for each part) which prevents the main record from being overloaded.  Regarding the usage of $5's, the example 3 seems to be a valid one, as item specific information is included.  Whereas example 4 slightly moves the meaning of subfield $5 into a direction of source or provenance information, which we would like to see expressed in a different way (similar to field 883).

Discussion Paper 2016-DP02:
Clarifying Code Values in Field 008/20 (Format of Music) in the MARC 21 Bibliographic Format
http://www.loc.gov/marc/mac/2016/2016-dp02.html 

In general, we support this paper.  Up to now, the RDA terms and definitions do not fully fit into the MARC codes and definitions.  We see the risk of legacy data (pre-RDA) already coded on 008 Music position 20, which now would slightly be shifted in its meaning.  For "piano score" there may be a need for a MARC code of its own, instead of subsuming it under "z" = "other".

Discussion Paper 2016-DP03:
Recording Distributor Number for Music and Moving Image Materials in the MARC 21 Bibliographic Format
http://www.loc.gov/marc/mac/2016/2016-dp03.html 

We support this paper.  With field 264 and its second indicator value "2" = "distribution", it is consequent to handle numbers similarly.

Discussion Paper 2016-DP04:
Extending the Use of Subfield $0 (Authority record control number or standard number) to Encompass Linking Fields
http://www.loc.gov/marc/mac/2016/2016-dp04.html 

In general, we support this paper.  Having a URI to express the type of relationship in the 76X - 78X fields will be helpful.  However the proposed definition of $0 does not seem to be the best possible solution to us.  It has the disadvantage that $0 does not clearly say that it provides _type_ _of_ _relationship_ information, and the issue of sequencing subfields arises.  We suggest using $4 instead, which up to now is defined as "Relationship code".  This subfield should be trimmed to carry information in form of a URI also (similar to $0 which has evolved from record control numbers only to any kind of standard identifiers, incl. URI's).  Doing so would keep the semantics of the control subfield $4 clean, but expand its syntax.  Up to now, there is a subfield $4 in the 76X - 78X fields, but no code list behind it.

Discussion Paper 2016-DP05:
Expanding the Definition of Subfield $w (Bibliographic record control number) to Encompass Standard Numbers
http://www.loc.gov/marc/mac/2016/2016-dp05.html 

We fully support this paper.  Extending $w in the same way as $0 already has been (and $4 and maybe other control subfields will hopefully be) will be very helpful.  With multiple $w's (as in example 4) the pairing of URI-style $w's and their non-URI-style counterparts may become a minor issue.

Discussion Paper 2016-DP06:
Define Subfield $2 and Subfield $0 in Field 753 of the MARC 21 Bibliographic Format
http://www.loc.gov/marc/mac/2016/2016-dp06.html 

We support this paper.  Field 753 and the extensions discussed here provide a far better control than the free text information in field 538.  We can imagine implementing field 753 and using it by linking to the GND.

Discussion Paper 2016-DP07:
Broaden Usage of Field 257 to Include Autonomous Regions in the MARC 21 Bibliographic Format
http://www.loc.gov/marc/mac/2016/2016-dp07.html 

We support this paper.

Discussion Paper 2016-DP08:
Remove Restriction on the Use of Dates in Field 046 $k of the MARC 21 Bibliographic Format
http://www.loc.gov/marc/mac/2016/2016-dp08.html 

We support this paper.  Redundant bits of information should not be an issue any more here.

Discussion Paper 2016-DP09:
Coding Named Events in the MARC 21 Authority and Bibliographic Formats
http://www.loc.gov/marc/mac/2016/2016-dp09.html 

Defining a new type of entity "Named event" and a prominent group of fields "X47" looks interesting.  According to GND policies, libraries in German speaking countries use topical subject headings = the X50 fields for single historical events ("Historische Einzelereignisse"), coded as "sih" according to http://www.dnb.de/SharedDocs/Downloads/DE/DNB/standardisierung/inhaltserschliessung/entitaetenCodes.pdf  (cf. the GND paper at  http://www.loc.gov/marc/mac/2016/2016-dp14.html ).

There were mixed opinions inside our group: some prefer the X11 approach (mixing up events being agents and events not being agents), others prefer the existing X50 way.  Defining X47 would have significant implications when it comes to implementing them.  What about other types of entities to be accommodated by additional groups of fields, e.g. "Family"?

Discussion Paper 2016-DP10:
Defining Field 347 (Digital File Characteristics) in the MARC 21 Holdings Format
http://www.loc.gov/marc/mac/2016/2016-dp10.html 

In general we support this paper.  The provider-neutral record approach is not very often followed by libraries in German speaking countries.  In addition to field 347, more fields of the MARC Bibliographic Format may have to be mirrored into the MARC Holdings Format.

---

As the Discussion Papers 2016-DP11 through 2016-DP16 are brought to the table by ourselves, there's no need to comment on them here.

Best wishes,

Reinhold Heuvelmann

--

Reinhold Heuvelmann
German National Library
Information Infrastructure
Office for Data Formats
Adickesallee 1
D-60322 Frankfurt am Main
Germany
Telephone: +49 (0) 69 1525-1709
Telefax: +49 (0) 69 1525-1799
mailto:[log in to unmask]
http://www.dnb.de

*** Reading. Listening. Understanding. German National Library ***