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 stuart.yea...@vuw.ac.nz 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...)
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=googleauinit=ABaulast=Milleratitle=Reporting+results+of+cancer+treatmentid=doi:10.1002/1097-0142%2819810101%2947:1%3C207::AID-CNCR2820470134%3E3.0.CO%3B2-6title=Cancervolume=47issue=1date=2006spage=207issn=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 completetrue/complete 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=googleauinit=ABaulast=Milleratitle=Reporting+results+of+cancer+treatmentid=doi:10.1002/1097-0142%2819810101%2947:1%3C207::AID-CNCR2820470134%3E3.0.CO%3B2-6title=Cancervolume=47issue=1date=2006spage=207issn=0008-543X Ross Singer wrote: On Fri, Apr 30, 2010 at 10:08 AM, Eric Hellman e...@hellman.net 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...)
Quoting Jakob Voss jakob.v...@gbv.de: 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...)
On Mon, May 3, 2010 at 6:34 PM, Karen Coyle li...@kcoyle.net wrote: Quoting Jakob Voss jakob.v...@gbv.de: 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...)
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...)
Ross Singer wrote: On Fri, Apr 30, 2010 at 11:52 AM, Mike Taylor m...@indexdata.com wrote: On 30 April 2010 16:42, Ed Summers e...@pobox.com wrote: On Fri, Apr 30, 2010 at 11:33 AM, Ross Singer rossfsin...@gmail.com 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
Stuart Yeates wrote: A great deal of heat has been vented in this thread, and at least a little light. I'd like to invite everyone to contribute to the wikipedia page at http://en.wikipedia.org/wiki/OpenURL in the hopes that it evolves into a better overview of the protocol, the ecosystem and their place on th web. [Hint: the best heading for a rant wikipedia is 'criticisms' but you'll still need to reference the key points. Links into this thread count as references, if you can't find anything else.] Good point - but writing Wikipedia articles is more work than discussing on mailing lists ;-) Instead of improving the OpenURL article I started to add to the more relevant[1] COinS article: http://en.wikipedia.org/wiki/COinS Maybe some of you (Eric Hellman, Richard Cameron, Daniel Chudnov, Ross Singer, Herbert Van de Sompel ...) could fix the history section which I tried to reconstruct from historic sources[2] from the Internet without violating the Wikipedia NPOV which is hard if you write about things you were involved at. Am I right that neither OpenURL nor COinS strictly defines a metadata model with a set of entities/attributes/fields/you-name-it and their definition? Apparently all ContextObjects metadata formats are based on non-normative implementation guidelines only ?? Cheers Jakob [1] My bet: What will remain from OpenURL will be a link server base URL that you attach a COinS to [2] about five years ago, so its historic in terms of internet ;-) By the way does anyone have a copy of http://dbk.ch.umist.ac.uk/wiki/index.php?title=Metadata_in_HTML ? -- Jakob Voß jakob.v...@gbv.de, 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...)
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 e...@pobox.com wrote: On Thu, Apr 29, 2010 at 12:08 PM, Eric Hellman e...@hellman.net 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Jakob Voss schrieb: ... Am I right that neither OpenURL nor COinS strictly defines a metadata model with a set of entities/attributes/fields/you-name-it and their definition? Apparently all ContextObjects metadata formats are based on non-normative implementation guidelines only ?? You are right, the 129 page spec of Z39.88 only deals with these in examples, and IIRC does not even decent pointers to the following: There are some Core Metadata formats registered under http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=ListRecordsmetadataPrefix=oai_dcset=Core:Metadata+Formats notably info:ofi/fmt:kev:mtx:book and info:ofi/fmt:kev:mtx:journal : http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:book , http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:journal . As for the semantics of the fields defined there, the description is certainly not strictly defined in any sense but you can already see that there is potential for confusion and especially no canonical way (no way at all?) to achieve satisfying descriptions for several kinds of non-mainstream objects: * scholarly articles originally published online (when a journal context cannot be constructed) * articles in books which are not by coincidence conference proceedings ... ciao Thomas Berger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iJwEAQECAAYFAkvamhkACgkQYhMlmJ6W47P/vQP/XfExoDcfEuMGIgFUw4z4GOiM LhFsKPkVR7wHKDgB+mEF+xnDJoP549Y31YEYKc5lMMz5fVMONUDwwiavVL6IdDvL EU2jDOQO+WnLiw1XENYoTiuEP6bxyF+gojlBlEN7De1OlCJ97gqitwz6owmTxvp0 BfjBcj4X8//5KVMD0rw= =1a4i -END PGP SIGNATURE-
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
On Fri, Apr 30, 2010 at 4:09 AM, Jakob Voss jakob.v...@gbv.de wrote: Am I right that neither OpenURL nor COinS strictly defines a metadata model with a set of entities/attributes/fields/you-name-it and their definition? Apparently all ContextObjects metadata formats are based on non-normative implementation guidelines only ?? You are right. Z39.88 and (by extension) COinS really only defines the ContextObject itself. So it defines the carrier package, it's administrative elements, referents, referrers, referringentities, services, requester and resolver and their transports. It doesn't really specify what should actually go into any of those slots. The idea is that it defers to the community profiles for that. In the XML context object, you can send more than one metadata-by-val element (or metadata-by-ref) per entity (ref, rfr, rfe, svc, req, res) - I'm not sure what is supposed to happen, for example, if you send a referent that has multiple MBV elements that don't actually describe the same thing. -Ross.
Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)
On Fri, Apr 30, 2010 at 7:59 AM, Kyle Banerjee kyle.baner...@gmail.com 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...)
On Fri, Apr 30, 2010 at 9:09 AM, Ross Singer rossfsin...@gmail.com 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...)
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 e...@pobox.com wrote: On Thu, Apr 29, 2010 at 12:08 PM, Eric Hellman e...@hellman.net 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...)
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...)
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
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 e...@hellman.net 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...)
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ß jakob.v...@gbv.de, 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
On 4/29/10 12:32 PM, MJ Suhonos 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.
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.
One key thing to remember with the W3C work is that URL's have to be
dereference-able. I can't lookup (without an OpenLink resolver or Google
or the like) a url:isbn:{whatever}, but I can dereference
http://dbpedia.org/resource/The_Lord_of_the_Rings -- which 303's to
http://dbpedia.org/page/The_Lord_of_the_Rings -- which is full of more
/resource/ dereferencable (via 303 See Other) URL's.
The main thing that the W3C was trying to avoid was RDF that
inadvertently talks about online documents when what it really wants to
talk about is the real thing. Real things (like books) need a URI, but
ideally a URI that can be dereferenced (via HTTP in this case) to give
them some information about that real thing--which isn't possible with
the urn:isbn style schemes.
That's my primitive understanding of it anyway. Apologies if any
overlaps with library tech are off. :)
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 str name=array1water/str 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. Keep on dreaming Jakob :-)
Re: [CODE4LIB] it's cool to hate on OpenURL
A great deal of heat has been vented in this thread, and at least a little light. I'd like to invite everyone to contribute to the wikipedia page at http://en.wikipedia.org/wiki/OpenURL in the hopes that it evolves into a better overview of the protocol, the ecosystem and their place on th web. [Hint: the best heading for a rant wikipedia is 'criticisms' but you'll still need to reference the key points. Links into this thread count as references, if you can't find anything else.] 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 Fri, Apr 30, 2010 at 04:17, Jakob Voss jakob.v...@gbv.de 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...)
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 10:54, Eric Hellman e...@hellman.net 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...)
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 e...@hellman.net 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...)
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
