Take a look at "Best Practices for Shareable Metadata": http://webservices.itcs.umich.edu/mediawiki/oaibp/index.php/ShareableMetadataPublic
There is a specific section on "Linking from a Record to a Resource and Other Linking Issues".
Regards,
Tom
> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of
> Joe Hourcle
> Sent: Monday, February 27, 2012 10:43 AM
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] "Repositories", OAI-PMH and web crawling
>
> On Feb 27, 2012, at 10:51 AM, Godmar Back wrote:
> > On Mon, Feb 27, 2012 at 8:31 AM, Diane Hillmann
> <[log in to unmask]>wrote:
> >> On Mon, Feb 27, 2012 at 5:25 AM, Owen Stephens
> <[log in to unmask]> wrote:
>
> >>> This issue is certainly not unique to VT - we've come across this as
> >>> part of our project. While the OAI-PMH record may point at the PDF,
> >>> it can
> >> also
> >>> point to a intermediary page. This seems to be standard practice in
> >>> some instances - I think because there is a desire, or even
> >>> requirement, that
> >> a
> >>> user should see the intermediary page (which may contain rights
> >> information
> >>> etc.) before viewing the full-text item. There may also be an issue
> >>> where multiple files exist for the same item - maybe several data
> >>> files and a
> >> pdf
> >>> of the thesis attached to the same metadata record - as the metadata
> >>> via OAI-PMH may not describe each asset.
> >>>
> >>>
> >> This has been an issue since the early days of OAI-PMH, and many
> >> large providers provide such intermediate pages (arxiv.org, for
> >> instance). The other issue driving providers towards intermediate
> >> pages is that it allows them to continue to derive statistics from
> >> usage of their materials, which direct access URIs and multiple web
> >> caches don't. For providers dependent on external funding, this is a
> biggie.
> >>
> > Why do you place direct access URI and multiple web caches into the
> > same category? I follow your argument re: usage statistics for web
> > caches, but as long as the item remains hosted in the repository
> > direct access URIs should still be counted (provided proper
> > cache-control headers are sent.) Perhaps it would require server-side
> statistics rather than client-based GA.
>
> I'd agree -- if you can't get good statistics from direct linking, something's
> wrong with the methods you're using to collect usage information. Google
> Analytics and similar tools might produce pretty reports, but they're really
> meant for tracking web sites and won't work when someone has javascript
> turned off, has specifically blacklisted the analytics server, or on anything
> that's not HTML.
>
> You *really* need to analyze the server logs directly, as you can't be sure
> that all access is going to go through the intermediate 'landing pages' or that
> it'd be tracked even if they did.
>
> ...
>
> I admit, the stuff I'm serving is a little different than most people on this list,
> but we also have the issue that the collections are so large that we don't
> want people retrieving the files unless they really need them. We serve
> multiple TB per day -- I'd rather a person figure out if they want a file
> *before* they retrieve it, rather than download a few GB of data and find
> out it won't serve their purposes.
>
> It might not help our 'look how much we serve!' metrics to justify our
> funding, but it helps keep our costs down, and I personally believe it helps
> with good will in our designated community as they don't spend a day (or
> more) downloading only to find it's not what they thought. (and it fits in with
> Ranganathan's 4th law better than saving them from an extra click)
>
> -Joe
|
