 |
 |
A suggestion on how to get a prof to enter a url. I use this bookmarklet to add a URL to Hacker News: javascript:window.location=%22http://news.ycombinator.com/submitlink?u=%22+encodeURIComponent(document.location)+%22&t=%22+encodeURIComponent(document.title) I'm tempted to suggest an api based on OpenURL, but I fear the 10 emails it would provoke. On Sep 15, 2009, at 10:56 AM, Ross Singer wrote: > 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). >> Eric Hellman President, Gluejar, Inc. 41 Watchung Plaza, #132 Montclair, NJ 07042 USA [log in to unmask] http://go-to-hellman.blogspot.com/