Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
On Mon, May 3, 2010 at 9:14 PM, stuart yeates wrote: > Bill Dueber wrote: > >> "if the librarians would grow a pair >> and demand better data via our contracts" > > While I agree with your overall point, it would have been better made with > the gendered phrasing, in my view. I agree, and I apologize. There's enough of that nonsense in the programming world, and I need to watch my cliches. I amend to wishing that librarians would either (a) grow a spine, or (b) get, you know, better legal advice when it comes time to play chicken with sole-providers. Which is less colorful, but perhaps more accurate. -Bill- -- Bill Dueber Library Systems Programmer University of Michigan Library
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
Bill Dueber wrote: "if the librarians would grow a pair and demand better data via our contracts" While I agree with your overall point, it would have been better made with the gendered phrasing, in my view. cheers stuart -- Stuart Yeates http://www.nzetc.org/ New Zealand Electronic Text Centre http://researcharchive.vuw.ac.nz/ Institutional Repository
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
On Mon, May 3, 2010 at 6:34 PM, Karen Coyle wrote: > Quoting Jakob Voss : > >> I bet there are several reasons why OpenURL failed in some way but I >> think one reason is that SFX got sold to Ex Libris. Afterwards there >> was no interest of Ex Libris to get a simple clean standard and most >> libraries ended up in buying a black box with an OpenURL label on it - >> instead of developing they own systems based on a common standard. I >> bet you can track most bad library standards to commercial vendors. I >> don't trust any standard without open specification and a reusable Open >> Source reference implementation. > > For what it's worth, that does not coincide with my experience. I'm going to turn this back on Karen and say that much of my pain does come from vendors, but it comes from their shitty data. OpenURL and resolvers would be a much more valuable piece of technology if the vendors would/could get off their collective asses(1) and give us better data. -Bill- (1) By this, of course, I mean "if the librarians would grow a pair and demand better data via our contracts" -- Bill Dueber Library Systems Programmer University of Michigan Library
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
Quoting Jakob Voss : I bet there are several reasons why OpenURL failed in some way but I think one reason is that SFX got sold to Ex Libris. Afterwards there was no interest of Ex Libris to get a simple clean standard and most libraries ended up in buying a black box with an OpenURL label on it - instead of developing they own systems based on a common standard. I bet you can track most bad library standards to commercial vendors. I don't trust any standard without open specification and a reusable Open Source reference implementation. For what it's worth, that does not coincide with my experience. kc -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
Karen Coyle wrote: It's a shame. I can see the reasons why the committee took it the way they did, but the whole exercise has ended up smelling of architecture astronautics. See this column if you're not familiar with the term, it's a good read: http://www.joelonsoftware.com/articles/fog18.html Speaking as someone who was on the committee, I can tell you that there was not a consensus on "going astronautic." Although some of us fought a good (well, at least hard) fight, the astronauts won. And if you think the text of the final standard is dense, you should have seen version 0.1! Eric Hellman wrote a revised version that was 1) in English 2) made sense, but that, too, was rejected. If you want to see my reaction to being presented with the "Bison Fute'" model [1] on the first day of the OpenURL committee meeting, download this [2] PPT and play it as a slide show (it is self-animated). (It helps you get the joke if you know that "Bison Fute'" means "wily buffalo".) kc [1] http://www.dlib.org/dlib/july01/vandesompel/07vandesompel.html [2] http://kcoyle.net/presentations/cpm3.ppt LOL! :-) I bet there are several reasons why OpenURL failed in some way but I think one reason is that SFX got sold to Ex Libris. Afterwards there was no interest of Ex Libris to get a simple clean standard and most libraries ended up in buying a black box with an OpenURL label on it - instead of developing they own systems based on a common standard. I bet you can track most bad library standards to commercial vendors. I don't trust any standard without open specification and a reusable Open Source reference implementation. Cheers Jakob -- Jakob Voß , skype: nichtich Verbundzentrale des GBV (VZG) / Common Library Network Platz der Goettinger Sieben 1, 37073 Göttingen, Germany +49 (0)551 39-10242, http://www.gbv.de
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
Here is the API response Umlaut provides to OpenURL requests with standard scholarly formats. This API response is of course to some extent customized to Umlaut's particular context/use cases, it was not neccesarily intended to be any kind of standard -- certainly not with as wide-ranging intended domain as OpenURL's 1.0 intent (which never really caught on), it's targetted at standard actually-existing link resolver use cases in the scholarly environment. But, here you go, live even: http://findit.library.jhu.edu/resolve/api?sid=google&auinit=AB&aulast=Miller&atitle=Reporting+results+of+cancer+treatment&id=doi:10.1002/1097-0142%2819810101%2947:1%3C207::AID-CNCR2820470134%3E3.0.CO%3B2-6&title=Cancer&volume=47&issue=1&date=2006&spage=207&issn=0008-543X Json is also available. Note that complete results do not neccesarily show up at first, some information is still being loaded in the background. You can refresh the URL to see more results, you'll know when the back-end server has nothing left to give you when true is present. Another XML response with embedded HTML snippets is also available (in both XML and Json): http://findit.library.jhu.edu/resolve/partial_html_sections?sid=google&auinit=AB&aulast=Miller&atitle=Reporting+results+of+cancer+treatment&id=doi:10.1002/1097-0142%2819810101%2947:1%3C207::AID-CNCR2820470134%3E3.0.CO%3B2-6&title=Cancer&volume=47&issue=1&date=2006&spage=207&issn=0008-543X Ross Singer wrote: On Fri, Apr 30, 2010 at 10:08 AM, Eric Hellman wrote: OK, what does the EdSuRoSi spec for OpenURL responses say? Well, I don't think it's up to us and I think it's dependent upon community profile (more than Z39.88 itself), since it would be heavily influenced with what is actually trying to be accomplished. I think the basis of a response could actually be another context object with the 'services' entity containing a list of services/targets that are formatted in some way that is appropriate for the context and the referent entity enhanced with whatever the resolver can add to the puzzle. This could then be taken to another resolver for more services layered on. This is just riffing off the top of my head, of course... -Ross.
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
I'll try to find out. Sent from Eric Hellman's iPhone On May 2, 2010, at 4:10 PM, stuart yeates wrote: But the interesting use case isn't OpenURL over HTTP, the interesting use case (for me) is OpenURL on a disconnected eBook reader resolving references from one ePub to other ePub content on the same device. Can OpenURL be used like that?
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
Ross Singer wrote: On Fri, Apr 30, 2010 at 11:52 AM, Mike Taylor wrote: On 30 April 2010 16:42, Ed Summers wrote: On Fri, Apr 30, 2010 at 11:33 AM, Ross Singer wrote: Just to clarify -- OpenURL 1.0 does not assume HTTP is being used. Oh, so that's the problem! Yes! Exactly! Poor old OpenURL 1.0 is abstracted to hell and back. The sad old thing doesn't even know what transport it's running on (why? Because Abstraction Is Good, not because anyone actually had any reason for wanting to use a different transport than HTTP), and as a result it can't assume it has, for example, the ability for the transport to report errors. Of course, per Eric's earlier comment, there's no reason why we can't take what's there and refine it so that there are assumptions like HTTP and optimize it to actually *work* in such an environment. Is there? But the interesting use case isn't OpenURL over HTTP, the interesting use case (for me) is OpenURL on a disconnected eBook reader resolving references from one ePub to other ePub content on the same device. Can OpenURL be used like that? cheers stuart -- Stuart Yeates http://www.nzetc.org/ New Zealand Electronic Text Centre http://researcharchive.vuw.ac.nz/ Institutional Repository
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
Quoting Mike Taylor : It's a shame. I can see the reasons why the committee took it the way they did, but the whole exercise has ended up smelling of architecture astronautics. See this column if you're not familiar with the term, it's a good read: http://www.joelonsoftware.com/articles/fog18.html Speaking as someone who was on the committee, I can tell you that there was not a consensus on "going astronautic." Although some of us fought a good (well, at least hard) fight, the astronauts won. And if you think the text of the final standard is dense, you should have seen version 0.1! Eric Hellman wrote a revised version that was 1) in English 2) made sense, but that, too, was rejected. If you want to see my reaction to being presented with the "Bison Fute'" model [1] on the first day of the OpenURL committee meeting, download this [2] PPT and play it as a slide show (it is self-animated). (It helps you get the joke if you know that "Bison Fute'" means "wily buffalo".) kc [1] http://www.dlib.org/dlib/july01/vandesompel/07vandesompel.html [2] http://kcoyle.net/presentations/cpm3.ppt -- Karen Coyle kco...@kcoyle.net http://kcoyle.net ph: 1-510-540-7596 m: 1-510-435-8234 skype: kcoylenet
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
COinS showed that is in fact possible to do so- there are probably more COinS in the wild than OpenURLs. I was thinking more along the lines of Ed's suggestion, (request headers, too) although I previously had implemented something along the lines of what Ross suggested. On Apr 30, 2010, at 11:56 AM, Ross Singer wrote: > Of course, per Eric's earlier comment, there's no reason why we can't > take what's there and refine it so that there are assumptions like > HTTP and optimize it to actually *work* in such an environment. > > Is there? > > -Ross. On Apr 30, 2010, at 11:21 AM, Ed Summers wrote: > I doubt I understand the full scope of the problem (never made it > through the spec myself). But I imagine a sensible use of HTTP status > codes would've gotten most of the way there. > > //Ed Eric Hellman President, Gluejar, Inc. 41 Watchung Plaza, #132 Montclair, NJ 07042 USA e...@hellman.net http://go-to-hellman.blogspot.com/
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
> Well, that's what the "Community Profiles" are. So now you have TWO > long, dense, boring documents to read -- the standard and the profile! > > The main game in town for Making OpenURL 1.0 Usable (maybe still the > only game, come to think of it) is the San Antonio Profile, or SAP for > short, which you can get here: >http://alcme.oclc.org/openurl/docs/pdf/SanAntonioProfile.pdf > Happily, it's only eight pages long (i.e. the same length as the > entire original OpenURL 0.1 specification). The bad news is, they are > incredible dense pages. Sample statement: > > > > Have fun with that! Funny, I feel the same way when I read many of the Dublin Core specifications, and they have helpful diagrams and example code blocks to boot! :-) MJ
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
On 30 April 2010 16:56, Ross Singer wrote: > On Fri, Apr 30, 2010 at 11:52 AM, Mike Taylor wrote: >> On 30 April 2010 16:42, Ed Summers wrote: >>> On Fri, Apr 30, 2010 at 11:33 AM, Ross Singer wrote: Just to clarify -- OpenURL 1.0 does not assume HTTP is being used. >>> >>> Oh, so that's the problem! >> >> Yes! Exactly! >> >> Poor old OpenURL 1.0 is abstracted to hell and back. The sad old >> thing doesn't even know what transport it's running on (why? Because >> Abstraction Is Good, not because anyone actually had any reason for >> wanting to use a different transport than HTTP), and as a result it >> can't assume it has, for example, the ability for the transport to >> report errors. >> > > Of course, per Eric's earlier comment, there's no reason why we can't > take what's there and refine it so that there are assumptions like > HTTP and optimize it to actually *work* in such an environment. > > Is there? Well, that's what the "Community Profiles" are. So now you have TWO long, dense, boring documents to read -- the standard and the profile! The main game in town for Making OpenURL 1.0 Usable (maybe still the only game, come to think of it) is the San Antonio Profile, or SAP for short, which you can get here: http://alcme.oclc.org/openurl/docs/pdf/SanAntonioProfile.pdf Happily, it's only eight pages long (i.e. the same length as the entire original OpenURL 0.1 specification). The bad news is, they are incredible dense pages. Sample statement: D.5.5 Transports Transports define how to transport representations of ContextObjects over the network. Table D.7 lists the Transports supported by the San Antonio Community Profiles. The By-Value OpenURL Transport and the By-Reference OpenURL Transport (over HTTP and HTTPS) may be used to transport ContextObjects represented by means of the Key/Encoded-Value and the XML ContextObject Format. In case of the Key/Encoded-Value representation, only a single ContextObject may be transported. In case of the XML representation, one or more ContextObjects may be transported. The Inline OpenURL Transport may only be used to transport a single ContextObject represented using the KEV ContextObject Format. Have fun with that!
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
On Fri, Apr 30, 2010 at 11:52 AM, Mike Taylor wrote: > On 30 April 2010 16:42, Ed Summers wrote: >> On Fri, Apr 30, 2010 at 11:33 AM, Ross Singer wrote: >>> Just to clarify -- OpenURL 1.0 does not assume HTTP is being used. >> >> Oh, so that's the problem! > > Yes! Exactly! > > Poor old OpenURL 1.0 is abstracted to hell and back. The sad old > thing doesn't even know what transport it's running on (why? Because > Abstraction Is Good, not because anyone actually had any reason for > wanting to use a different transport than HTTP), and as a result it > can't assume it has, for example, the ability for the transport to > report errors. > Of course, per Eric's earlier comment, there's no reason why we can't take what's there and refine it so that there are assumptions like HTTP and optimize it to actually *work* in such an environment. Is there? -Ross. > It's a shame. I can see the reasons why the committee took it the way > they did, but the whole exercise has ended up smelling of architecture > astronautics. See this column if you're not familiar with the term, > it's a good read: > http://www.joelonsoftware.com/articles/fog18.html >
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
On 30 April 2010 16:42, Ed Summers wrote: > On Fri, Apr 30, 2010 at 11:33 AM, Ross Singer wrote: >> Just to clarify -- OpenURL 1.0 does not assume HTTP is being used. > > Oh, so that's the problem! Yes! Exactly! Poor old OpenURL 1.0 is abstracted to hell and back. The sad old thing doesn't even know what transport it's running on (why? Because Abstraction Is Good, not because anyone actually had any reason for wanting to use a different transport than HTTP), and as a result it can't assume it has, for example, the ability for the transport to report errors. It's a shame. I can see the reasons why the committee took it the way they did, but the whole exercise has ended up smelling of architecture astronautics. See this column if you're not familiar with the term, it's a good read: http://www.joelonsoftware.com/articles/fog18.html
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
On Fri, Apr 30, 2010 at 11:33 AM, Ross Singer wrote: > Just to clarify -- OpenURL 1.0 does not assume HTTP is being used. Oh, so that's the problem!
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
On Fri, Apr 30, 2010 at 11:21 AM, Ed Summers wrote: > > I doubt I understand the full scope of the problem (never made it > through the spec myself). But I imagine a sensible use of HTTP status > codes would've gotten most of the way there. Just to clarify -- OpenURL 1.0 does not assume HTTP is being used. This is not an endorsement of that view, just stating the facts. -Ross.
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
On Fri, Apr 30, 2010 at 10:43 AM, Eric Hellman wrote: > Eek. I was hoping for something much simpler. Do you realize that you're > asking for service taxonomy? I doubt I understand the full scope of the problem (never made it through the spec myself). But I imagine a sensible use of HTTP status codes would've gotten most of the way there. //Ed
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
On Fri, Apr 30, 2010 at 10:43 AM, Eric Hellman wrote: > Eek. I was hoping for something much simpler. Do you realize that you're > asking for service taxonomy? > Yes. I think you'd have to have one, otherwise how would you know what to expect from the results? If the target only offered TOCs or something, you would want to distinguish that from a target that offers fulltext or ILL fulfillment. I mean, right? How would you propose a response, Eric? I'm not sold on the ctx idea (in fact, I'd love something simpler), I just thought it would tie a nice bow around the existing spec :) -Ross. > On Apr 30, 2010, at 10:22 AM, Ross Singer wrote: > >> I think the basis of a response could actually be another context >> object with the 'services' entity containing a list of >> services/targets that are formatted in some way that is appropriate >> for the context and the referent entity enhanced with whatever the >> resolver can add to the puzzle. >
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
Eek. I was hoping for something much simpler. Do you realize that you're asking for service taxonomy? On Apr 30, 2010, at 10:22 AM, Ross Singer wrote: > I think the basis of a response could actually be another context > object with the 'services' entity containing a list of > services/targets that are formatted in some way that is appropriate > for the context and the referent entity enhanced with whatever the > resolver can add to the puzzle.
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
Hi All, Though hesitant to jump in here, I agree with Owen that the dead ends aren't a standards issue. The bloat of the standard is, as is the lack of a standardized response format, but the dead ends have to do with bad metadata being coded into open-URLs and with breakdowns in the connection between content aggregators/providers and knowledge base maintainers. Work in this area isn't completely stagnant, though. The joint NISO/UK Serials Group's "Knowledge Bases And Related Tools working group" is looking towards solutions to exactly these problems. http://www.uksg.org/kbart Their initial report on best practice for content providers and KB maintainers is worth a look. -Corey Owen Stephens wrote: Dead ends from OpenURL enabled hyperlinks aren't a result of the standard though, but rather an aspect of both the problem they are trying to solve, and the conceptual way they try to do this. I'd content these dead ends are an implementation issue - and despite this I have to say that my experience on the ground is that feedback from library users on the use of link resolvers is positive - much more so than many of the other library systems I've been involved with. What I do see as a problem is that this market seems to have essentially stagnated, at least as far as I can see. I suspect the reasons for this are complex, but it would be nice to see some more innovation in this area. Owen On Thu, Apr 29, 2010 at 6:14 PM, Ed Summers wrote: On Thu, Apr 29, 2010 at 12:08 PM, Eric Hellman wrote: Since this thread has turned into a discussion on OpenURL... I have to say that during the OpenURL 1.0 standardization process, we definitely had moments of despair. Today, I'm willing to derive satisfaction from "it works" and overlook shortcomings. It might have been otherwise. Personally, I've followed enough OpenURL enabled hyperlink dead ends to contest "it works". //Ed -- Corey A Harper Metadata Services Librarian New York University Libraries 20 Cooper Square, 3rd Floor New York, NY 10003-7112 212.998.2479 corey.har...@nyu.edu
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
On Fri, Apr 30, 2010 at 10:08 AM, Eric Hellman wrote: > OK, what does the EdSuRoSi spec for OpenURL responses say? > Well, I don't think it's up to us and I think it's dependent upon community profile (more than Z39.88 itself), since it would be heavily influenced with what is actually trying to be accomplished. I think the basis of a response could actually be another context object with the 'services' entity containing a list of services/targets that are formatted in some way that is appropriate for the context and the referent entity enhanced with whatever the resolver can add to the puzzle. This could then be taken to another resolver for more services layered on. This is just riffing off the top of my head, of course... -Ross.
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
Although part of the problem is that you might want to offer any service on the basis of an OpenURL the major use case is supply of a document (either online or via ILL) - so it strikes me you could look at DAIA http://www.gbv.de/wikis/cls/DAIA_-_Document_Availability_Information_API ? Jakob does this make sense? Owen On Fri, Apr 30, 2010 at 3:08 PM, Eric Hellman wrote: > OK, what does the EdSuRoSi spec for OpenURL responses say? > > Eric > > On Apr 30, 2010, at 9:40 AM, Ed Summers wrote: > > > On Fri, Apr 30, 2010 at 9:09 AM, Ross Singer > wrote: > >> I actually think this lack of any specified response format is a large > >> factor in the stagnation of OpenURL as a technology. Since a resolver > >> is under no obligation to do anything but present a web page it's > >> difficult for local entrepreneurial types to build upon the > >> infrastructure simply because there are no guarantees that it will > >> work anywhere else (or even locally, depending on your vendor, I > >> suppose), much less contribute back to the ecosystem. > > > > I agree. And that's an issue with the standard, not the implementations. > > > > //Ed > > Eric Hellman > President, Gluejar, Inc. > 41 Watchung Plaza, #132 > Montclair, NJ 07042 > USA > > e...@hellman.net > http://go-to-hellman.blogspot.com/ > -- Owen Stephens Owen Stephens Consulting Web: http://www.ostephens.com Email: o...@ostephens.com
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
OK, what does the EdSuRoSi spec for OpenURL responses say? Eric On Apr 30, 2010, at 9:40 AM, Ed Summers wrote: > On Fri, Apr 30, 2010 at 9:09 AM, Ross Singer wrote: >> I actually think this lack of any specified response format is a large >> factor in the stagnation of OpenURL as a technology. Since a resolver >> is under no obligation to do anything but present a web page it's >> difficult for local entrepreneurial types to build upon the >> infrastructure simply because there are no guarantees that it will >> work anywhere else (or even locally, depending on your vendor, I >> suppose), much less contribute back to the ecosystem. > > I agree. And that's an issue with the standard, not the implementations. > > //Ed Eric Hellman President, Gluejar, Inc. 41 Watchung Plaza, #132 Montclair, NJ 07042 USA e...@hellman.net http://go-to-hellman.blogspot.com/
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
On Fri, Apr 30, 2010 at 9:09 AM, Ross Singer wrote: > I actually think this lack of any specified response format is a large > factor in the stagnation of OpenURL as a technology. Since a resolver > is under no obligation to do anything but present a web page it's > difficult for local entrepreneurial types to build upon the > infrastructure simply because there are no guarantees that it will > work anywhere else (or even locally, depending on your vendor, I > suppose), much less contribute back to the ecosystem. I agree. And that's an issue with the standard, not the implementations. //Ed
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
On Fri, Apr 30, 2010 at 7:59 AM, Kyle Banerjee wrote: > An obvious thing for a resolver to be able to do is return results in JSON > so the OpenURL can be more than a static link. But since the standard > defines no such response, the site generating the OpenURL would have to know > something about the resolver. > I actually think this lack of any specified response format is a large factor in the stagnation of OpenURL as a technology. Since a resolver is under no obligation to do anything but present a web page it's difficult for local entrepreneurial types to build upon the infrastructure simply because there are no guarantees that it will work anywhere else (or even locally, depending on your vendor, I suppose), much less contribute back to the ecosystem. Umlaut was able to exist because (for better or worse) SFX has an XML output. It has never been able to scale horizontally, however, because to work with another vendor's link resolver (which should actually be quite straightforward) it requires a connector to whatever *their* proprietary API needs. I could definitely see a project like Umlaut providing a 'de facto' machine readable response for SAP 1/2 requests that content providers could then use to start offering better integration at *their* end. This assumes that more than 5 libraries would actually be using it, however. -Ross.
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
> Dead ends from OpenURL enabled hyperlinks aren't a result of the standard > though, but rather an aspect of both the problem they are trying to solve, > and the conceptual way they try to do this. > > I'd content these dead ends are an implementation issue. Absolutely. There is no inherent reason that an OpenURL has to be a plain text link that must be manually clicked nor is there any requirement that the resolver simply return an HTML page that may or may not contain plain text links the user can click on. An obvious thing for a resolver to be able to do is return results in JSON so the OpenURL can be more than a static link. But since the standard defines no such response, the site generating the OpenURL would have to know something about the resolver. > What I do see as a problem is that this market seems to have essentially > stagnated, at least as far as I can see. I suspect the reasons for this are > complex I suspect they are simple. The easy part of OpenURL addresses a compelling use case, but there just isn't that much pressure to take things to the next level. If people really got that upset about dead links -- and in many systems this is impossible because you'll be offered ILL fulfillment if no electronic copy is available -- there would be more incentive to handle resolution before the user clicks on the link. In short, you reach a point of diminishing returns with OpenURL very quickly. kyle
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
Dead ends from OpenURL enabled hyperlinks aren't a result of the standard though, but rather an aspect of both the problem they are trying to solve, and the conceptual way they try to do this. I'd content these dead ends are an implementation issue - and despite this I have to say that my experience on the ground is that feedback from library users on the use of link resolvers is positive - much more so than many of the other library systems I've been involved with. What I do see as a problem is that this market seems to have essentially stagnated, at least as far as I can see. I suspect the reasons for this are complex, but it would be nice to see some more innovation in this area. Owen On Thu, Apr 29, 2010 at 6:14 PM, Ed Summers wrote: > On Thu, Apr 29, 2010 at 12:08 PM, Eric Hellman wrote: > > Since this thread has turned into a discussion on OpenURL... > > > > I have to say that during the OpenURL 1.0 standardization process, we > definitely had moments of despair. Today, I'm willing to derive satisfaction > from "it works" and overlook shortcomings. It might have been otherwise. > > Personally, I've followed enough OpenURL enabled hyperlink dead ends > to contest "it works". > > //Ed > -- Owen Stephens Owen Stephens Consulting Web: http://www.ostephens.com Email: o...@ostephens.com
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
Eric Hellman wrote: May I just add here that of all the things we've talked about in > these threads, perhaps the only thing that will still be in use a > hundred years from now will be Unicode. إن شاء الله Sadly, yes, I agree with you on this. Do you have any idea how demotivating that is for those of us maintaining collections with works containing characters that don't qualify for inclusion? cheers stuart -- Stuart Yeates http://www.nzetc.org/ New Zealand Electronic Text Centre http://researcharchive.vuw.ac.nz/ Institutional Repository
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
Ha! One of the things OpenURL 1.0 "fixed" was to wire in UTF-8 encoding. Much of the MARC data in circulation also uses UTF-8 encoding. Some of it even uses it correctly. On Apr 29, 2010, at 8:58 PM, Alexander Johannesen wrote: > On Fri, Apr 30, 2010 at 10:54, Eric Hellman wrote: >> May I just add here that of all the things we've talked about in these >> threads, perhaps the only thing that will still be in use a hundred years >> from now will be Unicode. إن شاء الله > > May I remind you that we're still using MARC. Maybe you didn't mean in > the library world ... *rimshot* > > > Alex > -- > Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps > --- http://shelter.nu/blog/ -- > -- http://www.google.com/profiles/alexander.johannesen ---
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
On Fri, Apr 30, 2010 at 10:54, Eric Hellman wrote: > May I just add here that of all the things we've talked about in these > threads, perhaps the only thing that will still be in use a hundred years > from now will be Unicode. إن شاء الله May I remind you that we're still using MARC. Maybe you didn't mean in the library world ... *rimshot* Alex -- Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps --- http://shelter.nu/blog/ -- -- http://www.google.com/profiles/alexander.johannesen ---
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
May I just add here that of all the things we've talked about in these threads, perhaps the only thing that will still be in use a hundred years from now will be Unicode. إن شاء الله On Apr 29, 2010, at 7:40 PM, Alexander Johannesen wrote: > However, I'd like to add here that I happen to love XML, even from an > integration perspective, but maybe that stems from understanding all > those tedious bits no one really cares about about it, like id(s) and > refid(s) (and all the indexing goodness that comes from it), canonical > datasets, character sets and Unicode, all that schema craziness > (including Schematron and RelaxNG), XPath and XQuery (and all the > sub-standards), XSLT and so on. I love it all, and not because of the > generic simplicity itself (simple in the default mode of operation, I > might add), but because of a) modeling advantages, b) > cross-environment language and schema support, and c) ease of > creation. (I don't like how easy well-formedness breaks, though. That > sucks) Eric Hellman President, Gluejar, Inc. 41 Watchung Plaza, #132 Montclair, NJ 07042 USA e...@hellman.net http://go-to-hellman.blogspot.com/
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
On Fri, Apr 30, 2010 at 04:17, Jakob Voss wrote: > But all the flaws of XML can be traced back to SGML which is why we now use > JSON despite all of its limitations. Hmm, this is wrong on so many levels. First, SGML was pretty darn good for its *purpose*, but it was a geeks dream and pretty scary for anyone who hacked at it not fully getting it (like most normal developers). As with many things where the learning curve is steep, it fell into the "not good for normal consumption" category and they (well, people who cared, and made decisions about the web) were "forced" to make XML. But JSON? Are you sure you've got this figured out? JSON as a object serializing format is good for a number of things (small footprint, embedded type, etc.), but sucks for most information management tasks. However, I'd like to add here that I happen to love XML, even from an integration perspective, but maybe that stems from understanding all those tedious bits no one really cares about about it, like id(s) and refid(s) (and all the indexing goodness that comes from it), canonical datasets, character sets and Unicode, all that schema craziness (including Schematron and RelaxNG), XPath and XQuery (and all the sub-standards), XSLT and so on. I love it all, and not because of the generic simplicity itself (simple in the default mode of operation, I might add), but because of a) modeling advantages, b) cross-environment language and schema support, and c) ease of creation. (I don't like how easy well-formedness breaks, though. That sucks) But I mention all this for a specific reason ; MARCXML is the work of the devil! There's a certain dedication needed for "doing it right", by paying attention in XML class, and play well with your playmates. This is how you build a community and understanding around standards; the standards themselves are not enough. The library world did nothing of the kind ; http://shelter.nu/blog/2008/09/marcxml-beast-of-burden.html The flaws of XML can most likely be traced back to people not playing well with playmates, and not the format itself. > May brother Ted Nelson enlighten all of > us - he not only hates XML [1] and similar formats but also proposed an > alternative way to structure information even before the invention of > hierarchical file systems and operating systems [2]. Bah. For someone who don't see the SGML -> XML -> HTML transgression as an inherited and more rigid structure (or, by popular language, more schematic) as a document model as a good thing, I'm not impressed. Any implied structure can be criticized, including pretty much any corner of Xanadu as well. (I mean, seriously; taking hypermedia one step closer to a file system does *not* solve problems with the paper-based document model of HTTP, it just shifts the focus) > In his vision of Xanadu > every piece of published information had a unique ID that was reused > everytimes the publication was referenced - which would solve our problem. *Having* an identifier doesn't mean that identifier is a *good* one, nor that it solves your problem. There's plenty of systems out there where everything has an identifier (and, if you knew XML deeper, you'll find identification models as well in there, but people don't use them because the early onset of XML didn't understand nor need them). Have a look at the failed XLink brooha for something that worked and filled the niche, but people didn't get nor did tool-makers see the point of implementation, and the thing died a premature death. The current model of document structure and XQuery is somewhat of an alternative, but people are also switching to CSS3 styles as well. The thing is, just because you've got persistence in a system of identifiers, it does not follow that the information is persisted; the problem of change is *not* solved in neither systems, and so we work with the one we got and make the best of it. One thing I always found intriguing about librarians were their commitment to persistent URIs for information resources, and use of 303 if need be (although I see this mindset dwindling). I think you're the only ones in the entire world who gives a monkeys bottom about these issues, as the rest of the world simply use Google as a resolver. I can see where this is going. :) Regards, Alex -- Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps --- http://shelter.nu/blog/ -- -- http://www.google.com/profiles/alexander.johannesen ---
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
> But all the flaws of XML can be traced back to SGML which is > why we now use JSON despite all of its limitations. excuse me, but JSON is something completely different. It is an object notation and in not at all usable to structure data. XML is great to describe complex data, but it is often badly used, like in MARC XML (ISO 2709 described in XML). And it is musunderstood by a lot of programmmers that only thing in strings, integers and the lot
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
Eric Hellman wrote: What I hope for is that OpenURL 1.0 eventually takes a place alongside SGML as a too-complex standard that directly paves the way for a universally adopted foundational technology like XML. What I fear is that it takes a place alongside MARC as an anachronistic standard that paralyzes an entire industry. But all the flaws of XML can be traced back to SGML which is why we now use JSON despite all of its limitations. May brother Ted Nelson enlighten all of us - he not only hates XML [1] and similar formats but also proposed an alternative way to structure information even before the invention of hierarchical file systems and operating systems [2]. In his vision of Xanadu every piece of published information had a unique ID that was reused everytimes the publication was referenced - which would solve our problem. SCNR Jakob [1] http://ted.hyperland.com/XMLisEvil.html [2] Ted Nelson: A File Structure for the Complex, The Changing and the Indeterminate, ACM 20th National Conference, pages 84-100, 1965. Presented in 1964. -- Jakob Voß , skype: nichtich Verbundzentrale des GBV (VZG) / Common Library Network Platz der Goettinger Sieben 1, 37073 Göttingen, Germany +49 (0)551 39-10242, http://www.gbv.de
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
Even the best standard in the world can only do so much! On Apr 29, 2010, at 1:14 PM, Ed Summers wrote: > On Thu, Apr 29, 2010 at 12:08 PM, Eric Hellman wrote: >> Since this thread has turned into a discussion on OpenURL... >> >> I have to say that during the OpenURL 1.0 standardization process, we >> definitely had moments of despair. Today, I'm willing to derive satisfaction >> from "it works" and overlook shortcomings. It might have been otherwise. > > Personally, I've followed enough OpenURL enabled hyperlink dead ends > to contest "it works". > > //Ed
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
On Thu, Apr 29, 2010 at 12:08 PM, Eric Hellman wrote: > Since this thread has turned into a discussion on OpenURL... > > I have to say that during the OpenURL 1.0 standardization process, we > definitely had moments of despair. Today, I'm willing to derive satisfaction > from "it works" and overlook shortcomings. It might have been otherwise. Personally, I've followed enough OpenURL enabled hyperlink dead ends to contest "it works". //Ed
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
> What I hope for is that OpenURL 1.0 eventually takes a place alongside SGML > as a too-complex standard that directly paves the way for a universally > adopted foundational technology like XML. What I fear is that it takes a > place alongside MARC as an anachronistic standard that paralyzes an entire > industry. Hear hear. I'm actually encouraged by Benjamin's linking (har har) to the httpRange-14 issue as being relevant to the concept of "link resolution", or at least redirection (indirection?) using URL surrogates for resources. Many are critical of the TAG's "resolution" (har har har) of the issue, and think it places too much on the 303 redirect. I'm afraid I still don't understand the issue fully enough to comment — though I'd love to hear from any who can. I agree with Eric's hope that the library world can look to W3C's thinking to inform a "better way" forward for link resolving, though. Which causes me to wonder whether I should mention some disturbing research we're finding within PKP that using identifiers (DOIs, Purls, Handles) for resolving resources (notably journal articles) actually *decreases* search engine relevance because most link resolvers (including CrossRef) use 302 redirects instead of 303s, which Google "ignores" (but some suspect treats as spam, and thus demotes the target domain). Actually, no, I won't mention that. Carry on. MJ
