I see multiple "carrier" functions:
1) exchange of data between cooperating libraries cataloging in RDA
2) data format internal to, or compatible with, systems so that they can
be designed to be sold to the mass of libraries, even those not
cataloging in RDA or using some variant
3) data format for exchange with non-library or non-cooperating partners
4) data format for exposure of data displayed in browsers
For #1 & #2, I'm not sure that I'd recommend RDF. An expanded XML format
(one that didn't include the limitations of MARCXML) might be a better
choice. #3 probably has to be a suite of profiles that vary in their
degree of detail and their serialization. These could be "on the fly"
selections from the more detailed data in #1 and #2, probably through
some API.[1] For #4, much of "data exchange" is beginning to take place
via browser displays, today characterized by schema.org.
These may not be the only or the correct carrier functions, so I would
be interested to hear from others on this topic.
kc
[1] There is a proposal for an RFC that does content negotiation based
on profiles:
https://profilenegotiation.github.io/I-D-Accept--Schema/I-D-accept-schema
This will be taken up by the Dataset eXchange Working Group of W3C:
https://www.w3.org/2017/dxwg/wiki/Main_Page
On 11/14/17 9:31 AM, Joseph Kiegel wrote:
> An important function of the MARC record is as a carrier for the
> exchange of bibliographic data. In its early days, BIBFRAME was also
> described as a carrier, although this is not often done today. (The
> need for the exchange of data is acknowledged in the description of the
> BIBFRAME Initiative [1].) I raise the issue because I consider it
> important when assessing BIBFRAME for use within the library community,
> specifically, within the RDA cataloging community.
>
> It is obvious we will continue to exchange bib data for quite some
> time. The current model is to have local databases, both in libraries
> and library suppliers (vendors, publishers, etc.). When we move to a
> linked data world, we could potentially share one big (virtual) database
> of works, instances, agents, topics, etc., where only holdings
> information would be stored locally. But this is years away, even if we
> were able to agree on doing it. For the foreseeable future, then, we
> will exchange bib data among local databases. If we are encoding RDA
> cataloging data in BIBFRAME, then BIBFRAME becomes our carrier.
>
> This brings up the floor/ceiling problem I mentioned in an earlier
> post. Whatever standard we use for a carrier, it will be supported
> widely. But anything beyond that, anything that supplements the
> carrier, will be implemented spottily. In effect, any floor standard
> for a carrier becomes a ceiling because only the standard will be
> supported in all systems. This does not have to be true in theory, but
> in practice it will be.
>
> A consequence of carrier as ceiling is that we need a carrier that fully
> supports RDA. We want to exchange all of our RDA data with each other
> to facilitate user success in discovery. Experience with MARC
> demonstrates that we need a single international standard: we exchange
> data worldwide and it took MARC 21 to finally achieve this with ease.
> Recent changes to MARC for RDA also demonstrate how important it is to
> have a carrier that supports RDA.
>
> In summary, BIBFRAME will necessarily be a carrier, and to do that
> effectively for the library community it must support RDA fully.
>
>
>
> [1] https://www.loc.gov/bibframe/faqs/#q01
>
>
>
>
>
>
>
--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600
|
