If there’s one MARC field that needs an over-haul, it’s the 856. Roy has already talked about how it’s pretty much impossible to tell what the url in an 856 represents with relation to the item cataloged.
But here’s a question for you, let’s say you have an 856 URL to full text for a serial. And you know what date ranges it covers. What sub-field would you put that in? $3 or $z? I see it in both. $3 seems somewhat more appropriate, but $3 also often contains various other kinds of information, such as the name of the provider, or the chapters of a monograph that are covered. Or even a human-readable description of whether the link represents full text at all, or just tables of contents etc — most 856 fields don’t have this at all, but when they do it’s usually in the $3.
So basically, if you want software to be able to tell the user what range of dates is covered in full text, from the MARC, forget about it. And that’s not even talking about trying to get a machine processable range of dates, so software could actually calculate whether a particular date/issue is included. Even finding a simple display string representing dates of coverage is pretty much infeasible.
For how significant links to electronic versions (or supplementary information) has become, I’m kind of amazed that the 856 spec and practice hasn’t really been changed since the early days of the WWW. Probably becuase most of our ILS’s wouldn’t be able to handle it anyway. A vicious circle, as we generally run into with MARC.
Just for a start,
- A way to encode in machine-recognizable way whether the link represents full text, or just excerpts, or something else entirely (like a review). Right now full text and excerpts are coded the same — when they’re coded at all. As Roy’s paper discusses.
- A field for extent of coverage that is actually used only for extent of coverage. The $3 is theoretically this, but people throw all sorts of stuff into it. And possibly different fields for date range extent of coverage, vs. other extent of coverage (like for a monograph, chapter 3 only, or volume 1 only, etc). [Yes, it now occurs to me that the way this interacts with the first bullet point needs to be thought through].
- A field for displayable provider/platform.
And that’s just the low-hanging fruit. Then we start wanting the provider/platform to not just be human readable, but controlled in some way (URIs?), so we can collocate by provider/platform.
And then we start thinking about how we really want the dates of coverage for a serial to be machine actionable so software can compute if a particular date/issue is included. Which gets us thinking about Marc Format for Holdings, which is it’s own entirely gigantic mess. I don’t think this kind of ‘holdings’ data is usually used at all with records with an 856 representing electronic full text. But even if they were, typical MFHD use makes it pretty infeasible for software to actually answer this question.