IG Week Session QA (both from Zoom “Chat” & “QA”)
Q: Why would anyone need to convert BIBFRAME to MARC? I thought BIBFRAME was replacing MARC.
A: in order to serve other ILS components, modules, cataloging can be accomplished via BIBFRAME, however, e.g. circulation, cannot
A: I think as more places start initial cataloging in BIBFRAME there will still be a lot of systems that rely only on MARC so those BIBFRAME records will need to be converted
A: Perhaps for libraries that remain with MARC.
A: libraries will be creating original records in bibframe, and at some point those of us who still use marc will want to use those records.
A: [Steve] Not everyone will convert to BIBFRAME, and certainly not all at the same time. The Library of Congress is already in the process of changing to BIBFRAME, so after transition all records from LC will have to be converted to MARC to go into OCLC. In fact, until LC gets a new ILS (they expect to move to a Koha implementation), records they catalog in BIBFRAME will have to be converted to MARC so they can be used in their own public catalog.
A: and then, there's the vendors--who need to get onboard with the whole idea of BIBFRAME
A: [Ben]: I don't think BIBFRAME will replace MARC any time soon; I think they will continue to lead parallel existences for the foreseeable future. Libraries are not great at making sudden, uniform pivots to new technologies... OCLC printed its final catalog card in 2015. The question in my mind is how the bibliographic metadata ecosystem will look when LC and the other big institutions that are looking at moving to BIBFRAME make that shift. Will, for example, OCLC continue to be the, or at least the primary hub for metadata exchange?
Q: Please put link in chat [assuming this means Ben’s slide #8 spreadsheet called “Preliminary Repertoire of MARC Descriptive Fields from BIBFRAME”]
A: Link to spreadsheet
Q: Question for Ben--Can you explain what "lossy" means?
A: When there is a difference between the way an element is defined by BIBFRAME and the way the same element is defined by MARC there can be a loss of semantic information or specificity.
Q: For Ben, did you explore how using URIs in MARC encoding would affect conversion to/from BIBFRAME?
A: We did with respect to access points. We recommended looking at this as a possible way of converting BibFrame to MARC.
Q: Please explain "LD requires a URI that can be dereferenced into RDF"
A: [Steve] Linked Data relies on at least two of the elements being URIs. But you can't just use any URI. It must be a URI which returns more machine-actionable data, generally in some form of RDF. Some linked data URIs can return either machine-actional RDF or human-readable text/HTML/XML/etc., depending on how the link is retrieved. Wikidata is an example of this. You can look up a Wikidata link with a browser and see a human-readable description of the entity. But a linked-data server can retrieve data from the same link in a form which the server can work with, combining with data it already has or can retrieve from yet other sites.
A: [Jackie] There are options to optimize RDF URIs for computers to return values from the servers where the data reside. Combining with additional Web API tools, URI can embed additional data for visualization, the same data can appear in presentation in the form of tables, graphs, charts, etc. Where the URI in the form of URL lands user to a static document preset (designed) layout as a html or a PDF.
Q: For Steve - Which session tomorrow will discuss whether or not your recommendations were agreed with?
A: [Steve] Our final report will be discussed at the (closed) PCC Policy Committee (PoCo) meeting
A: [Jackie] The reference of tomorrow is the meeting with PoCo where both Steve and I will try to attend.
A: [Steve] Follow-up–PoCo will continue discussion of the report at their meeting in April.
Q: Data provenance at a really granular level - wouldn’t that require more than “triples” - possibly quads or more elemenets?
A: [Steve] the $7 have that granularity
A: [Steve] There has been some discussion on how to record data provenance in linked data at that granularity. Quads have been mentioned, with the fourth element perhaps being an identifier which could then be used as a subject in another quad for a data provenance statement about the first quad.
A: [Thurstan] Besides $7, other subfields were defined to carry data provenance in the MARC bib and authority where $7 was already defined for a different purpose:
https://www.loc.gov/marc/bibliographic/bdapndxj.html
https://www.loc.gov/marc/authority/adapndxh.html
A: [Thurstan] Besides identifiers, unstructured and structured descriptions could also be used to express a value of data provenance.
Q: To everyone, why has there not been more effort into employing linked data within the MARC encoding instead of creating or having to convert to BIBFRAME?
A: [Steve] There has been effort toward that, including the projects presented at this meeting. But MARC has a completely different structure than linked data. Lots of people have looked at it and concluded that MARC cannot support a proper linked data structure. The complexity of the $7 field is an example of how hard it is to use MARC like linked data.
A: [Thurstan] Over recent years significant efforts have been made to support linked data in a MARC context. The prevalence of $0 and $1 as a means of recording URIs is one indication of this. But the string based structure of MARC fields sometimes presents challenges in terms of associating a URI with a human readable data element in the same field. $7 (and other subfields by exception) can be used in combination with data provenance relationship codes to make such associations. This is a complex workaround, but one which the MARC Advisory Committee felt was simpler, more effective and achievable than all the other options considered:
https://www.loc.gov/marc/mac/2021/2021-dp10.html
A: [Ben] In my opinion even if MARC is made fully "linky" (i.e. URIs enabled for every field where they can be used) MARC will still find its primary as a textual encoding format for human consumption. URIs in MARC can play an important role in converting data stored in MARC to something else, or possibly in updating the textual values already in the record. But I don't think there will be an attempt to make MARC function as linked data.
A: [Jackie] MARC as a data format was to address bibliographic description in its totality and was designed to be used in a mainframe computer environment. Over the years, as system infrastructure evolved, components of the MARC format were adapted to address client/server environments when libraries began to move away from mainframe services. This is happening now with additional MARC proposals to try to make use of a data format that is over half a century old. It will come at a time, the ROI may not make sense to fit MARC in constantly changing Web environment. The work on BF started over a decade ago and has picked up momentum worldwide. It hopes to alleviate burden from library community as the ontology is based on the W3C data standard, RDF where data description is simplified in triples that allow a variety of connectors from point to point via PID (permanent identifier) in the form of http URIs.
Q: For all speakers--Is there a way to describe Nomen in MARC or are strings and things too conflated?
A: [Steve] Practically everything in MARC bib records is a Nomen. The difficulty in MARC is clearly identifying entities other than Nomen. That's where identifiers and URLs come in.
A: [Thurstan] The MARC formats conflate Nomen with other bibliographic and associated entities: Work / Expression / Manifestation; Person / Family / Corporate Body; Timespan / Place, etc.). We are familiar with recording individual Nomen elements in MARC (e.g. status of identification; undifferentiated name indicator), but to describe it as an entity in its own right could not be done within the existing framework of MARC formats; it would also be highly disruptive to existing record models such as NACO. Further analysis regarding this issue can be found in the MARC/RDA Workings Group’s final report:
https://www.loc.gov/marc/mac/MARC%20RDA%20Working%20Group%20-%20Final%20Report.pdf
A: [Ben] "Nomen" is a concept we've been using for a long time just without the word attached to it. For example, an access point in a MARC record is just a string but it's more than that–there is important information about the entity that that string represents. Some of it is in the MARC record itself (for example the tag tells you something about what kind of entity is being described or identified), and some is stored outside the bib. record in an authority record. So we are already "encoding Nomen" in MARC just not in the explicit way RDA-LRM advocates.
A: [Jackie] As noted by colleagues above, the nomen concept is not new. What is new is the <term> used to be an entity that may warrant an identifier.