Oh yeah, one thing I left off --

In Moodle, it would probably make sense to link to the URL in the <a> tag:
<a href="http://bbc.co.uk/">The Beeb!</a>
but use a javascript onMouseDown action to rewrite the link to route
through your funky link resolver path, a la Google.

That way, the page works like any normal webpage, "right mouse
click->Copy Link Location" gives the user the "real" URL to copy and
paste, but normal behavior funnels through the link resolver.

-Ross.

On Tue, Sep 15, 2009 at 11:41 AM, Ross Singer <[log in to unmask]> wrote:
> Given that the burden of creating these links is entirely on RefWorks
> & Telstar, OpenURL seems as good a choice as anything (since anything
> would require some other service, anyway).  As long as the profs
> aren't expected to mess with it, I'm not sure that *how* you do the
> indirection matters all that much and, as you say, there are added
> bonuses to keeping it within SFX.
>
> It seems to me, though, that your rft_id should be a URI to the db
> you're using to store their references, so your CTX would look
> something like:
>
> http://res.open.ac.uk/?rfr_id=info:/telstar.open.ac.uk&rft_id=http://telstar.open.ac.uk/1234&dc.identifier=http://bbc.uk.co/
> # not url encoded because I have, you know, a life.
>
> I can't remember if you can include both metadata-by-reference keys
> and metadata-by-value, but you could have by-reference
> (&rft_ref=http://telstar.open.ac.uk/1234&rft_ref_fmt=RIS or something)
> point at your citation db to return a formatted citation.
>
> This way your citations are unique -- somebody pointing at today's
> London Times frontpage isn't the same as somebody else's on a
> different day.
>
> While I'm shocked that I agree with using OpenURL for this, it seems
> as reasonable as any other solution.  That being said, unless you can
> definitely offer some other service besides linking to the resource,
> I'd avoid the resolver menu completely.
>
> -Ross.
>
> On Tue, Sep 15, 2009 at 11:17 AM, O.Stephens <[log in to unmask]> wrote:
>> Ross - no you didn't miss it,
>>
>> There are 3 ways that references might be added to the learning environment:
>>
>> An author (or realistically a proxy on behalf of the author) can insert a reference into a structured Word document from an RIS file. This structured document (XML) then goes through a 'publication' process which pushes the content to the learning environment (Moodle), including rendering the references from RIS format into a specified style, with links.
>> An author/librarian/other can import references to a 'resources' area in our learning environment (Moodle) from a RIS file
>> An author/librarian/other can subscribe to an RSS feed from a RefWorks 'RefShare' folder within the 'resources' area of the learning environment
>>
>> In general the project is focussing on the use of RefWorks - so although the RIS files could be created by any suitable s/w, we are looking specifically at RefWorks.
>>
>> How you get the reference into RefWorks is something we are looking at currently. The best approach varies depending on the type of material you are looking at:
>>
>> For websites it looks like the 'RefGrab-it' bookmarklet/browser plugin (depending on your browser) is the easiest way of capturing website details.
>> For books, probably a Union catalogue search from within RefWorks
>> For journal articles, probably a Federated search engine (SS 360 is what we've got)
>> Any of these could be entered by hand of course, as could several other kinds of reference
>>
>> Entering the references into RefWorks could be done by an author, but it more likely to be done by a member of clerical staff or a librarian/library assistant
>>
>> Owen
>>
>> Owen Stephens
>> TELSTAR Project Manager
>> Library and Learning Resources Centre
>> The Open University
>> Walton Hall
>> Milton Keynes, MK7 6AA
>>
>> T: +44 (0) 1908 858701
>> F: +44 (0) 1908 653571
>> E: [log in to unmask]
>>
>>
>>> -----Original Message-----
>>> From: Code for Libraries [mailto:[log in to unmask]] On
>>> Behalf Of Ross Singer
>>> Sent: 15 September 2009 15:56
>>> To: [log in to unmask]
>>> Subject: Re: [CODE4LIB] Implementing OpenURL for simple web resources
>>>
>>> Owen, I might have missed it in this message -- my eyes are
>>> starting glaze over at this point in the thread, but can you
>>> describe how the input of these resources would work?
>>>
>>> What I'm basically asking is -- what would the professor need
>>> to do to add a new:  citation for a 70 year old book; journal
>>> on PubMed; URL to CiteSeer?
>>>
>>> How does their input make it into your database?
>>>
>>> -Ross.
>>>
>>> On Tue, Sep 15, 2009 at 5:04 AM, O.Stephens
>>> <[log in to unmask]> wrote:
>>> >>True. How, from the OpenURL, are you going to know that the rft is
>>> >>meant to represent a website?
>>> > I guess that was part of my question. But no one has suggested
>>> > defining a new metadata profile for websites (which I
>>> probably would
>>> > avoid tbh). DC doesn't seem to offer a nice way of doing
>>> this (that is
>>> > saying 'this is a website'), although there are perhaps
>>> some bits and
>>> > pieces (format, type) that could be used to give some
>>> indication (but
>>> > I suspect not unambiguously)
>>> >
>>> >>But I still think what you want is simply a purl server. What makes
>>> >>you think you want OpenURL in the first place?  But I still don't
>>> >>really understand what you're trying to do: "deliver consistency of
>>> >>approach across all our references" -- so are you using OpenURL for
>>> >>it's more "conventional" use too, but you want to tack on a
>>> purl-like
>>> >>functionality to the same software that's doing something
>>> more like a
>>> >>conventional link resolver?  I don't completely understand
>>> your use case.
>>> >
>>> > I wouldn't use OpenURL just to get a persistent URL - I'd
>>> almost certainly look at PURL for this. But, I want something
>>> slightly different. I want our course authors to be able to
>>> use whatever URL they know for a resource, but still try to
>>> ensure that the link works persistently over time. I don't
>>> think it is reasonable for a user to have to know a 'special'
>>> URL for a resource - and this approach means establishing a
>>> PURL for all resources used in our teaching material whether
>>> or not it moves in the future - which is an overhead it would
>>> be nice to avoid.
>>> >
>>> > You can hit delete now if you aren't interested, but ...
>>> >
>>> > ... perhaps if I just say a little more about the project
>>> I'm working on it may clarify...
>>> >
>>> > The project I'm working on is concerned with referencing
>>> and citation. We are looking at how references appear in
>>> teaching material (esp. online) and how they can be reused by
>>> students in their personal environment (in essays, later
>>> study, or something else). The references that appear can be
>>> to anything - books, chapters, journals, articles, etc.
>>> Increasingly of course there are references to web-based materials.
>>> >
>>> > For print material, references generally describe the
>>> resource and nothing more, but for digital material
>>> references are expected not only to describe the resource,
>>> but also state a route of access to the resource. This tends
>>> to be a bad idea when (for example) referencing e-journals,
>>> as we know the problems that surround this - many different
>>> routes of access to the same item. OpenURLs work well in this
>>> situation and seem to me like a sensible (and perhaps the
>>> only viable) solution. So we can say that for
>>> journals/articles it is sensible to ignore any URL supplied
>>> as part of the reference, and to form an OpenURL instead. If
>>> there is a DOI in the reference (which is increasingly
>>> common) then that can be used to form a URL using DOI
>>> resolution, but it makes more sense to me to hand this off to
>>> another application rather than bake this into the reference
>>> - and OpenURL resolvers are reasonably set to do this.
>>> >
>>> > If we look at a website it is pretty difficult to reference
>>> it without including the URL - it seems to be the only good
>>> way of describing what you are actually talking about (how
>>> many people think of websites by 'title', 'author' and
>>> 'publisher'?). For me, this leads to an immediate confusion
>>> between the description of the resource and the route of
>>> access to it. So, to differentiate I'm starting to think of
>>> the http URI in a reference like this as a URI, but not
>>> necessarily a URL. We then need some mechanism to check,
>>> given a URI, what is the URL.
>>> >
>>> > Now I could do this with a script - just pass the URI to a
>>> script that checks what URL to use against a list and
>>> redirects the user if necessary. On this point Jonathan said
>>> "if the usefulness of your technique does NOT count on being
>>> inter-operable with existing link resolver infrastructure...
>>> PERSONALLY I would be using OpenURL, I don't think it's worth
>>> it" - but it struck me that if we were passing a URI to a
>>> script, why not pass it in an OpenURL? I could see a number
>>> of advantages to this in the local context:
>>> >
>>> > Consistency - references to websites get treated the same as
>>> > references to journal articles - this means a single
>>> approach on the
>>> > course side, with flexibility Usage stats - we could collect these
>>> > whatever, but if we do it via OpenURL we get this in the
>>> same place as
>>> > the stats about usage of other scholarly material and could
>>> consider
>>> > driving personalisation services off the data (like the bX product
>>> > from Ex Libris) Appropriate copy problem - for resources we
>>> subscribe
>>> > to with authentication mechanisms there is (I think) an
>>> equivalent to
>>> > the 'appropriate copy' issue as with journal articles - we
>>> can push a
>>> > URI to 'Web of Science' to the correct version of Web of
>>> Science via a
>>> > local authentication method (using ezproxy for us)
>>> >
>>> > The problem with the approach (as Nate and Eric mention) is
>>> that any approach that relies on the URI as a identifier
>>> (whether using OpenURL or a script) is going to have problems
>>> as the same URI could be used to identify different resources
>>> over time. I think Eric's suggestion of using additional
>>> information to help differentiate is worth looking at, but I
>>> suspect that this is going to cause us problems - although
>>> I'd say that it is likely to cause us much less work than the
>>> alternative, which is allocating every single reference to a
>>> web resource used in our course material it's own persistent URL.
>>> >
>>> > The use case we are currently looking at is only with our
>>> own (authenticated) learning environment - so these OpenURLs
>>> are not going to appear in the wild, so to some extent
>>> perhaps it doesn't matter what we do - but it still seems
>>> sensible to me to look at what 'good practice' might look like.
>>> >
>>> > I hope this is clear - I'm still struggling with some of
>>> this, and sometimes it doesn't make complete sense to me, but
>>> that's my best stab at explaining my thinking at the moment.
>>> Again, I appreciate the comments. Jonathan said "But you seem
>>> to understand what's up". I wish I did! I guess that I'm
>>> reasonably confident that the approach I'm describing has
>>> some chance of doing the job - whether it is the best
>>> approach I'm not so sure about.
>>> >
>>> > Owen
>>> >
>>> >
>>> > The Open University is incorporated by Royal Charter (RC
>>> 000391), an exempt charity in England & Wales and a charity
>>> registered in Scotland (SC 038302).
>>> >
>>>
>>
>>
>> The Open University is incorporated by Royal Charter (RC 000391), an exempt charity in England & Wales and a charity registered in Scotland (SC 038302).
>>
>