I apologize for the length of this response, but I think these are two slightly different cases, and each of them is different from the discussion of core metadata…
Speaking from (but not _for_) my own institution, I think we draw ancillary resources into a presentation in the "last mile" for a couple of reasons:
1) They're subsidiary. They're helpful enhancements to the presentation of a resource, but without them, the presentation would still be helpful. Without metadata enabling basic selection and retrieval, the presentation wouldn't be very helpful. I realize that the line here isn't totally bright: some patrons may very well elect to retrieve a certain resource based on its table of contents, for example.
2) They're not "ours". The situation around our rights to store that information isn't always totally clear, at least to me. {grin} We can't make a wholesale duplication of, say, book jacket images, because our contract forbids it. Perhaps we may cache them, to a certain extent. And for each such kind of sidecar service, the terms often vary considerably.
3) They have a cost to maintain. We wouldn't necessarily want to store that information even if we could, because we might rather use those resources for information that is of more importance locally.
As for link resolvers: I think we have to consider that some of the motivation for link resolvers revolves around the management, not of references, but of intellectual property. It's useful to indirect retrieval of some resources through specialized proxies because their providers (e.g. journal publishers) will only provide those resources to _some_ people who ask them for it (those who have paid, directly or indirectly) and only when certain credentials are presented. That's not to claim that there aren't other reasons for those systems, but I would suggest that in a purely open-access world, indexes and link resolvers (and the market in which they are traded) would look rather different than they do: they would look much more like the rest of the Web.
There's another, more technical point here. It's one of the reasons it's not really feasible to maintain a "stateless catalog", at least not right now, if we want to fulfill the expectations of discovery held by most library users. We can effectively load book images at the last minute because we don't search them, and we don't integrate that data (the images) within a set of search results. Those of us who need to integrate local catalog results with external search results (perhaps from journal index services) often find that it's very difficult to, for example, unify faceting information between the two, or be sure that subject headings are useful across both, or the like. Of course, we must do those things over the kind of metadata Bibframe intends to express. It's much, _much_ more practical to do that when you don't have to include the cost of backend network transactions in the expense of answering a search request.
So we need to make some kind of adjustable balance between freshness of data and "liveness" of action, and that's where many think caching and similar techniques should come into play. (For the technically-minded: Apache Stanbol's EntityHub system for storing RDF representations is a nice example of this kind of balance in a tool. It provides for local indexes that can be searched very quickly in front of network-retrieval backends, and it caches retrieved results when possible.)
---
A. Soroka
The University of Virginia Library
On Jun 30, 2014, at 10:28 AM, Charles Pennell <[log in to unmask]> wrote:
> But isn't this what we all do now with Syndetics content (book jackets, TOC, summaries), pointers to Google books, as well as those from OCA, Hathi, and other sources, and with our link resolvers and knowledgebases. This is pretty much non-mediated Web-based data that we haul up at the point of display, seemingly with some success. Is it that we trust those sources that we pay for but not those that are provided as a public service? Even when the creator/provider is LC, NLM, and other "trusted" bodies?
>
> Charley Pennell
> Principal Cataloger
> NCSU Libraries
>
>
> On Sun, Jun 29, 2014 at 8:15 AM, [log in to unmask] <[log in to unmask]> wrote:
> It's hard for me to imagine that those using linked library data will be putting what is retrieved from the network directly in front of their patrons without intervention. That's not really technically feasible, whatever the desire may be.
>
> We will need to be guided by the Web architecture and use a design with caching. If you cache remote linked data resources locally (and if you intend to give your patrons a reasonable experience, you will be caching) you can certainly make emendations into or out of the cache, processing data in whatever ways you see fit.
>
> ---
> A. Soroka
> The University of Virginia Library
>
> On Jun 28, 2014, at 12:23 PM, J. McRee Elrod <[log in to unmask]> wrote:
>
> > If/when our displays are created from remote linked data, what do we
> > do about problems with the source data? For example, missing
> > (Fictitious character) and animal species qualifiers?
> >
> > Many want logical consistency in their displays.
> >
> >
> > __ __ J. McRee (Mac) Elrod ([log in to unmask])
> > {__ | / Special Libraries Cataloguing HTTP://www.slc.bc.ca/
> > ___} |__ \__________________________________________________________
>
>
>
> --
> Charley Pennell
> Principal Cataloger
> NCSU Libraries
> North Carolina State University
|