date:20100429

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...)

2010-04-29 Thread Alexander Johannesen

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...)

2010-04-29 Thread Alexander Johannesen

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] Twitter annotations and library software

2010-04-29 Thread Alexander Johannesen

Hi,

On Thu, Apr 29, 2010 at 22:47, Walker, David  wrote:
> I would suggest it's more because, once you step outside of the
> primary use case for OpenURL, you end-up bumping into *other* standards.

These issues were raised all the back when it was created, as well. I
guess it's easy to be clever in hindsight. :) Here's what I wrote
about it 5 years ago (http://shelter.nu/blog-159.html) ;

So let's talk about 'Not invented here' first, because surely, we're
all guilty of this one from time to time. For example, lately I dug
into the ANSI/NISO Z39.88 -2004 standard, better known as OpenURL. I
was looking at it critically, I have to admit, comparing it to what I
already knew about Web Services, SOA, http,
Google/Amazon/Flickr/Del.icio.us API's, and various Topic Maps and
semantic web technologies (I was the technical editor of Explorers
Guide to the Semantic Web)

I think I can sum up my experiences with OpenURL as such; why? Why
have the library world invented a new way of doing things that already
can be done quite well already? Now, there is absolutely nothing wrong
with the standard per se (except a pretty darn awful choice of
name!!), so I'm not here criticising the technical merits and the work
put into it. No, it's a simple 'why' that I have yet to get a decent
answer to, even after talking to the OpenURL bigwigs about it. I mean,
come on; convince me! I'm not unreasonable, no truly, really, I just
want to be convinced that we need this over anything else.

Regards,

Alex
-- 
 Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
--- http://shelter.nu/blog/ --
-- http://www.google.com/profiles/alexander.johannesen ---

[CODE4LIB] Job Posting: Applications Programmer for Digital Scholarly Publishing, Univ. of Michigan Library

2010-04-29 Thread Morse, Jeremy

***Please excuse cross-posting***

Applications Programmer for Digital Scholarly Publishing

The Scholarly Publishing Office (SPO) seeks an Application Developer to
design and code the business and application logic for a variety of software
systems in support of digital scholarly publishing.  This position will work
in a team with a Database Developer and an Interface Developer to create new
applications for web delivery of content, and office productivity tools to
enhance production workflow, as well as maintaining and improving existing
systems.

Duties will center on two main areas of work: designing, building, and
migrating content into a new online publishing platform for our journal and
monograph collections; and collaborative projects with the University of
Michigan Press to create enhanced digital versions of their books and
community-based tools.

SPO is a unit of the MPublishing division of the University of Michigan
Library.  SPO is a highly collaborative environment that emphasizes team
goals, and our programmer team has the opportunity to work with a variety of
other technical units in the Library: Core Services and the Digital Library
Production Service (DLPS) and their work on the Hathi Trust.  We also
collaborate with the other divisions within MPublishing: the Deep Blue
institutional repository, the Copyright Office, the Text Creation
Partnership, and the University of Michigan Press. To learn more about what
we do, visit .

Required:
* Bachelor's degree
* Demonstrated experience with:
  * any applicable language, and willingness/ability to learn others
  * MySQL or similar database query language
  * Unix-like OS 
  * version control systems
  * object-oriented programming
  * application development in a production environment
* Commitment to writing clean, documented code
* Excellent verbal and written communication skills
* Intellectual curiosity and desire to discuss why we develop what we
develop. 

Desired:
* Experience with: 
  * XML and XSLT 
  * Perl and MySQL 
  * technical standards and practices of Web publishing
  * developing modules for Drupal or equivalent CMS
  * developing modules for WordPress
  * processing and delivering multimedia content
  * developing APIs, such as RESTful web services

FLSA: Exempt 
Hours: 40 hours/week
Target Salary Range: $40,000-$50,000

THIS IS A TWO YEAR APPOINTMENT (with the possibility for renewal)

Questions about this job description may be emailed to Jeremy Morse, Lead
Programmer, Scholarly Publishing Office: jgmo...@umich.edu
or refer to Job ID 39936 at http://umjobs.org/

Re: [CODE4LIB] it's cool to hate on OpenURL

2010-04-29 Thread stuart yeates

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


On 4/29/10 3:48 PM, Boheemen, Peter van 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.
 

excuse me, but JSON is something completely different. It is an object notation 
and in not at all usable to structure data.
Don't let the CouchDB guys know that: http://couchdb.apache.org/ or any 
of the other JSON-based API builders either.

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
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 (was: Twitter annotations...)

2010-04-29 Thread Boheemen, Peter van

> 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

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] Twitter annotations and library software

I vote (heh) for "d" which will look a lot like "c" anyway, but with 
smatterings of owl:sameAs and Range-14 style 303's to keep things 
interesting. :)


--
President
BigBlueHat
P: 864.232.9553
W: http://www.bigbluehat.com/
http://www.linkedin.com/in/benjaminyoung


On 4/29/10 2:01 PM, Jakob Voss wrote:

How about a bet instead of voting. In three years will there be:

a) No relevant Twitter annotations anyway
b) Twitter annotations but not used much for bibliographic data
c) A rich variety of incompatible bibliographic annotation standards
d) Semantic Web will have solved every problem anyway

Re: [CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

2010-04-29 Thread Jakob Voss


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] Twitter annotations and library software

2010-04-29 Thread Jakob Voss


Dear Tim,

you wrote:

So this is my recommended framework for proceeding. Tim, I'm afraid
you'll actually have to do the hard work yourself.


No, I don't. Because the work isn't fundamentally that hard. A
complex standard might be, but I never for a moment considered
anything like that. We have *512 bytes*, and it needs to be usable by
anyone. Library technology is usually fatally over-engineered, but
this is a case where that approach isn't even possible.


Jonathan did a very well summary - you just have to pick what you main 
focus of embedding bibliographic data is.



A) I favour using the CSL-Record format which I summarized at

http://wiki.code4lib.org/index.php/Citation_Style_Language

because I had in mind that people want to have a nice looking citation 
of the publication that someone tweeted about. The drawback is that CSL 
is less adopted and will not always fit in 512 bytes



B) If you main focus is to link Tweets about the same publication (and 
other stuff about this publication) than you must embed identifiers. 
LibraryThing is mainly based on two identifiers


1) ISBN to identify editions
2) LT work ids to identify works

I wonder why LT work ids have not picked up more although you thankfully 
provide a full mapping to ISBN at 
http://www.librarything.com/feeds/thingISBN.xml.gz but nevermind. I 
thought that some LT records also contain other identifiers such as OCLC 
number, LOC number etc. but maybe I am wrong. The best way to specify 
identifiers is to use an URI (all relevant identifiers that I know have 
an URI form). For ISBN it is


uri:isbn:{ISBN13}

For LT Work-ID you can use the URL with your .com top level domain:

http://www.librarything.com/work/{LTWORKID}

That would fit for tweets about books with an ISBN and for tweets about 
a work which will make 99.9% of tweets from LT about single publications 
anyway.



C) If your focus is to let people search for a publication in libraries 
than and to copy bibliographic data in reference management software 
then COinS is a way to go. COinS is based on OpenURL which I and others 
ranted about because it is a crapy library standard like MARC. But 
unlike other metadata formats COinS usually fits in less then 512 bytes. 
Furthermore you may have to deal with it for LibraryThing for libraries 
anyway.



Although I strongly favour CSL as a practising library scientist and 
developer I must admit that for LibraryThing the best way is to embed 
identifiers (ISBN and LT Work-ID) and maybe COinS. As long as 
LibraryThing does not open up to more complex publications like 
preprints of proceeding-articles in series etc. but mainly deals with 
books and works this will make LibraryThing users happy.


Then, three years from now, we can all conference-tweet about a CIL 
talk, about all the cool ways libraries are using Twitter, and how 
it's such a shame that the annotations standard wasn't designed with 
libraries in mind.


How about a bet instead of voting. In three years will there be:

a) No relevant Twitter annotations anyway
b) Twitter annotations but not used much for bibliographic data
c) A rich variety of incompatible bibliographic annotation standards
d) Semantic Web will have solved every problem anyway
..

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...)

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] Twitter annotations and library software

OK, back to Tim's specific question.

I'm not sure why you want to put bib data in a tweet at all for your 
application. Why not just use a shortened URL pointing at your page of 
metadata? That page could offer metadata via BIBO, Open Graph and FOAF in RDFa, 
COinS, RIS, etc. using established methods to serve multiple applications at 
once. When Twitter annotations come along, the URL can be put in the annotation 
field.

Eric

On Apr 21, 2010, at 6:08 AM, Tim Spalding wrote:

> Have C4Lers looked at the new Twitter annotations feature?
> 
> http://www.sitepoint.com/blogs/2010/04/19/twitter-introduces-annotations-hash-tags-become-obsolete/
> 
> I'd love to get some people together to agree on a standard book
> annotation format, so two people can tweet about the same book or
> other library item, and they or someone else can pull that together.
> 
> I'm inclined to start adding it to the "I'm talking about" and "I'm
> adding" links on LibraryThing. I imagine it could be easily added to
> many library applications too—anywhere there is or could be a "share
> this on Twitter" link, including OPACs, citation managers, library
> event feeds, etc.
> 
> Also, wouldn't it be great to show the world another interesting,
> useful and cool use of library data that OCLC's rules would prohibit?
> 
> So the question is the format. Only a maniac would suggest MARC. For
> size and other reasons, even MODS is too much. But perhaps we can
> borrow the barest of field names from MODS, COinS, or from the most
> commonly used bibliographic format, Amazon XML.
> 
> Thoughts?
> 
> Tim
> 
> -- 
> Check out my library at http://www.librarything.com/profile/timspalding

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...)

2010-04-29 Thread Ed Summers

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

[CODE4LIB] it's cool to hate on OpenURL (was: Twitter annotations...)

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.

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. 


Eric Hellman
President, Gluejar, Inc.
41 Watchung Plaza, #132
Montclair, NJ 07042
USA

e...@hellman.net 
http://go-to-hellman.blogspot.com/

Re: [CODE4LIB] Twitter annotations and library software

I still don't really see how what you're talking about would
practically be accomplished.

For one, to have "rft.subject", like you mention, would require using
the dublincore context set.  Since that wouldn't be useful on its own
for the services that link resolvers currently offer, OpenURL sources
(i.e. A&I database providers) would have to support SAP 2 (XML)
context objects so they can pass the book/journal/patent/etc. referent
metadata along with the Dublin Core referent metadata.  It also
becomes a POST rather than a simple link (GET).

What I'm saying is it ups the requirements on all ends of the
ecosystem, for what?

What you're talking about would be *much* more easily implemented via
SRU and CQL (or OpenSearch), anyway, since your example is really
performing a search.  Since OpenURL doesn't have any semblance of
standardized response format, a client wouldn't know what to do with
the response, anyway.

-Ross.

On Thu, Apr 29, 2010 at 11:29 AM, Rosalyn Metz  wrote:
> ok right now exlibris has a recommender service for sfx that stores
> metadata from an openurl.  lets say a vendor bothered to pass an
> element like rft.subject=hippo (which is most likely unlikely to
> happen since they can't even pass an issn half the time).  that
> subject got stored in the recommender service.
>
> next time a child saw something in ebsco animals about hippos they
> could click the find this button (or whatever it says) and the
> recommender service could bring up everything on hippos.  the openurl
> that would be passed would be something like
> http://your.linkresolver.com/name?rft.subject=hippo
>
> yes this is simplistic, but its more creative then say doing something
> boring like just bringing up the full text or doing something half ass
> creative like bringing up articles that are cited in the footnotes.
> and to say something like rft.subject (or whatever it might be called)
> is out of the scope of group profiles is a little absurd since we are
> talking about things that already have subjects attached to them (see
> any database or other library related system).
>
> of course you'll probably want to talk about next how subjects aren't
> standardized and that makes it possible.  that is true, but that isn't
> openurl's fault or the link resolvers fault, thats the database
> vendors who refuse to get with the program.
>
>
>
>
>
>
> On Thu, Apr 29, 2010 at 11:02 AM, Ross Singer  wrote:
>> On Thu, Apr 29, 2010 at 10:32 AM, Rosalyn Metz  wrote:
>>> I'm going to throw in my two cents.
>>>
>>> I dont think (and correct me if i'm wrong) we have mentioned once what
>>> a user might actually put in a twitter annotation.  a book title?  an
>>> article title? a link?
>>
>> I think the idea is these would be machine generated from an
>> application.  So, imagine LT, Amazon, Delicious Library or SFX having
>> a "Tweet this!" button and *that* provides the annotation (not the
>> user).
>>>
>>> i think creating some super complicated thing for a twitter annotation
>>> dooms it to failure.  after all, its twitter...make it short and
>>> sweet.
>>>
>> Indeed, it's limited.
>>
>>> also the 1.0 document for OpenURL isn't really that bad (yes I have
>>> read it).  a good portion of it is a chart with the different metadata
>>> elements.  also open url could conceivably refer to an animal and then
>>> link to a bunch of resources on that animal, but no one has done that.
>>>  i don't think that's a problem with OpenURL i think thats a problem
>>> with the metadata sent by vendors to link resolvers and librarians
>>> lack of creativity (yes i did make a ridiculous generalization that
>>> was not intended to offend anyone but inevitably it will).  having
>>> been a vendor who has worked with openurl, i know that the informaiton
>>> databases send seriously effects (affects?) what you can actually do
>>> in a link resolver.
>>>
>> No, this is the mythical promise of 1.0, but delivery is, frankly,
>> much more complicated than that.  It is impractical to expect an
>> OpenURL link resolver to make sense of any old thing you throw at it
>> and return sensible results.  This is the point of the community
>> profiles, to narrow the infinite possibilities a bit.  None of our
>> current profiles would support the scenario you speak of and I would
>> be surprised if such a service were to be devised, that it would be
>> built on OpenURL.
>>
>> I think it's very easy to underestimate how complicated it is to
>> actually build something using OpenURL since in the abstract it seems
>> like a very logical solution to any problem.
>>
>> -Ross.
>>>
>>>
>>>
>>>
>>> On Thu, Apr 29, 2010 at 10:23 AM, Tim Spalding  
>>> wrote:
 Can we just hold a vote or something?

 I'm happy to do whatever the community here wants and will actually
 use. I want to do something that will be usable by others. I also
 favor something dead simple, so it will be implemented. If we don't
 reach some sort of conclusion, this is an interesting

Re: [CODE4LIB] Twitter annotations and library software

2010-04-29 Thread Tim Spalding

> So this is my recommended framework for proceeding. Tim, I'm afraid you'll 
> actually have to do the hard work yourself.

No, I don't. Because the work isn't fundamentally that hard. A complex
standard might be, but I never for a moment considered anything like
that. We have *512 bytes*, and it needs to be usable by anyone.
Library technology is usually fatally over-engineered, but this is a
case where that approach isn't even possible.

> You aren't going to get something good just by getting some listserv to vote.

My suggestion was to have people interested in actually using it vote.

> Many of us involved in this discussion may find this intellectually 
> interesting, but may have no actual use _ourselves_ for such a format anyway.

Oh, I bet half of you guys have sharing buttons on your OPAC or
elsewhere. And many of you are on Twitter and, at least occasionally,
discuss a book.

> If Amazon or someone like that comes up with something, it will end up 
> becoming the 'de facto' standard, so I recommend trying to talk to Amazon to 
> see if they're thinking about this -- or just wait to see if/what Amazon 
> comes up with, and use that.

You're right. It's a thankless task to get even a subset of library
technologists to agree on something like this. It'd be less important
if I didn't know the Amazon solution will leave off key pieces
libraries need.

Then, three years from now, we can all conference-tweet about a CIL
talk, about all the cool ways libraries are using Twitter, and how
it's such a shame that the annotations standard wasn't designed with
libraries in mind.

Best,
Tim

Re: [CODE4LIB] Twitter annotations and library software

On Thu, Apr 29, 2010 at 11:21 AM, Jonathan Rochkind  wrote:
> (Last
> time I looked at Bibo, I recall there was no place to put a standard
> identifier like a DOI.  So maybe using Bibo + URI for standard identifier
> would suffice. etc.)

BIBO has all sorts of identifiers (including DOI):

http://bibotools.googlecode.com/svn/bibo-ontology/trunk/doc/dataproperties/doi___1125128004.html

As well as ISBN (10 and 13), ISSN/e-issn, LCCN, EAN, OCLCNUM, and more.

-Ross.

Re: [CODE4LIB] Twitter annotations and library software

2010-04-29 Thread Rosalyn Metz

ok right now exlibris has a recommender service for sfx that stores
metadata from an openurl.  lets say a vendor bothered to pass an
element like rft.subject=hippo (which is most likely unlikely to
happen since they can't even pass an issn half the time).  that
subject got stored in the recommender service.

next time a child saw something in ebsco animals about hippos they
could click the find this button (or whatever it says) and the
recommender service could bring up everything on hippos.  the openurl
that would be passed would be something like
http://your.linkresolver.com/name?rft.subject=hippo

yes this is simplistic, but its more creative then say doing something
boring like just bringing up the full text or doing something half ass
creative like bringing up articles that are cited in the footnotes.
and to say something like rft.subject (or whatever it might be called)
is out of the scope of group profiles is a little absurd since we are
talking about things that already have subjects attached to them (see
any database or other library related system).

of course you'll probably want to talk about next how subjects aren't
standardized and that makes it possible.  that is true, but that isn't
openurl's fault or the link resolvers fault, thats the database
vendors who refuse to get with the program.

On Thu, Apr 29, 2010 at 11:02 AM, Ross Singer  wrote:
> On Thu, Apr 29, 2010 at 10:32 AM, Rosalyn Metz  wrote:
>> I'm going to throw in my two cents.
>>
>> I dont think (and correct me if i'm wrong) we have mentioned once what
>> a user might actually put in a twitter annotation.  a book title?  an
>> article title? a link?
>
> I think the idea is these would be machine generated from an
> application.  So, imagine LT, Amazon, Delicious Library or SFX having
> a "Tweet this!" button and *that* provides the annotation (not the
> user).
>>
>> i think creating some super complicated thing for a twitter annotation
>> dooms it to failure.  after all, its twitter...make it short and
>> sweet.
>>
> Indeed, it's limited.
>
>> also the 1.0 document for OpenURL isn't really that bad (yes I have
>> read it).  a good portion of it is a chart with the different metadata
>> elements.  also open url could conceivably refer to an animal and then
>> link to a bunch of resources on that animal, but no one has done that.
>>  i don't think that's a problem with OpenURL i think thats a problem
>> with the metadata sent by vendors to link resolvers and librarians
>> lack of creativity (yes i did make a ridiculous generalization that
>> was not intended to offend anyone but inevitably it will).  having
>> been a vendor who has worked with openurl, i know that the informaiton
>> databases send seriously effects (affects?) what you can actually do
>> in a link resolver.
>>
> No, this is the mythical promise of 1.0, but delivery is, frankly,
> much more complicated than that.  It is impractical to expect an
> OpenURL link resolver to make sense of any old thing you throw at it
> and return sensible results.  This is the point of the community
> profiles, to narrow the infinite possibilities a bit.  None of our
> current profiles would support the scenario you speak of and I would
> be surprised if such a service were to be devised, that it would be
> built on OpenURL.
>
> I think it's very easy to underestimate how complicated it is to
> actually build something using OpenURL since in the abstract it seems
> like a very logical solution to any problem.
>
> -Ross.
>>
>>
>>
>>
>> On Thu, Apr 29, 2010 at 10:23 AM, Tim Spalding  wrote:
>>> Can we just hold a vote or something?
>>>
>>> I'm happy to do whatever the community here wants and will actually
>>> use. I want to do something that will be usable by others. I also
>>> favor something dead simple, so it will be implemented. If we don't
>>> reach some sort of conclusion, this is an interesting waste of time. I
>>> propose only people engaged in doing something along these lines get
>>> to vote?
>>>
>>> Tim
>>>
>>
>

Re: [CODE4LIB] Twitter annotations and library software


Benjamin Young wrote:
Additionally (as someone outside of the library community proper), 
OpenURL's dependence on resolvers would be the largest concern.


This is a misconception.  An OpenURL context object can be created to 
provide structured semantic citation information, without any dependence 
on a resolver.  Just as a way of serializing structured semantic 
citation information in a standard way.


This is basically what COinS does.

Now, the largest concern with OpenURL to me is actually just that it's 
way harder to understand and work with than it should be to meet it's 
primary use cases, and that means trying to use it as a standard for a 
new use case is probably asking for trouble in "adoption curve".


So here are the questions, my own summary analysis of this thread:

1.  What are the citations you think users would want to attach to a 
tweet? 
   a. Will they ALL have standard identifiers that can be expressed as 
some form of URI (ISBN, DOI, etc).
   b. Or are there an important enough subset of citations that will 
NOT have standard identifiers that you still want to support?



If you choose 'a' above, then the solution to me seems clear:  Simply 
attach a URI as your 'citation metadata' -- be willing to use "info:" 
URIs for ISBNs, ISSNs, LCCNs, OCLCnums, DOIs.   It should be clearly 
identified as "identifier for thing cited by this tweet" somehow, but 
the 'payload' is just a URI.   [ I know some people don't like 
non-resolvable info: URIs.  I like em, and THIS use case shows why. It 
allows you to attach an ISBN to a tweet as a URI right now today, 
keeping your metadata schema simple "just a URI" while still allowing 
ISBNs ].


And then we're done if we choose 'a' above, it's pretty simple.

If you choose 'b' above, then you need a way to identify (or "describe 
sufficient for identification")  publications that do not have standard 
identifiers.


An OpenURL context object using the standard "scholarly formats" (the 
only ones actually being used much in the real world) is ONE such way 
that is _actually_ being used today for _just_ this purpose.  So it 
would be worth looking at. You could try to use it "whole cloth", or you 
could just take the element schema from the "scholarly formats" and 
re-purpose it. You could try to fix some of it's problems. (There are 
many).


Or you could ignore OpenURL (or rather than ignore, review it briefly 
for ideas) and use one of the other formats that haven't really yet 
caught on yet,  but might be designed a lot better than OpenURL.   
Examples brought up in this thread include something by Jakob Voss (that 
I don't have the URL handy for), some kind of citation-in-json format 
(that I don't have the url handy for), and Bibo in RDF (that I don't 
have the url handy for).  If you decide to go with any of these, it's 
probably worth _comparing_ them to OpenURL to make sure what can be 
expressed in OpenURL with standard scholarly formats can _also_ be 
expressed in the format you chose. (Last time I looked at Bibo, I recall 
there was no place to put a standard identifier like a DOI.  So maybe 
using Bibo + URI for standard identifier would suffice. etc.)


So this is my recommended framework for proceeding. Tim, I'm afraid 
you'll actually have to do the hard work yourself.  Standards creation 
is hard.   You aren't going to get something good just by getting some 
listserv to vote.  Many of us involved in this discussion may find this 
intellectually interesting, but may have no actual use _ourselves_ for 
such a format anyway.  If Amazon or someone like that comes up with 
something, it will end up becoming the 'de facto' standard, so I 
recommend trying to talk to Amazon to see if they're thinking about this 
-- or just wait to see if/what Amazon comes up with, and use that.


Jonathan

Re: [CODE4LIB] Twitter annotations and library software

At #ldow2010 on Tuesday there was a presentation on "semantic" Twitter 
via TwitLogic:

http://twitlogic.fortytwo.net/

You can download the full paper if you're really curious:
http://events.linkeddata.org/ldow2010/papers/ldow2010_paper16.pdf

Twitter Annotations system was mentioned at the end as a possible side 
option. There's bound to be a good bit of talk in the Linked Data 
community on strapping RDF/RDFa into Twitter Annotations, but I believe 
that's still beginning.


Additionally (as someone outside of the library community proper), 
OpenURL's dependence on resolvers would be the largest concern. Anyone 
could build similar "real thing" URL's and use 303 See Other redirects 
to return one or more digital resources about that "real thing." See 
this for more information:

http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039

Enjoy the reads,
Benjamin

--
President
BigBlueHat
P: 864.232.9553
W: http://www.bigbluehat.com/
http://www.linkedin.com/in/benjaminyoung


On 4/29/10 10:32 AM, Rosalyn Metz wrote:

I'm going to throw in my two cents.

I dont think (and correct me if i'm wrong) we have mentioned once what
a user might actually put in a twitter annotation.  a book title?  an
article title? a link?

i think creating some super complicated thing for a twitter annotation
dooms it to failure.  after all, its twitter...make it short and
sweet.

also the 1.0 document for OpenURL isn't really that bad (yes I have
read it).  a good portion of it is a chart with the different metadata
elements.  also open url could conceivably refer to an animal and then
link to a bunch of resources on that animal, but no one has done that.
  i don't think that's a problem with OpenURL i think thats a problem
with the metadata sent by vendors to link resolvers and librarians
lack of creativity (yes i did make a ridiculous generalization that
was not intended to offend anyone but inevitably it will).  having
been a vendor who has worked with openurl, i know that the informaiton
databases send seriously effects (affects?) what you can actually do
in a link resolver.





On Thu, Apr 29, 2010 at 10:23 AM, Tim Spalding  wrote:
   

Can we just hold a vote or something?

I'm happy to do whatever the community here wants and will actually
use. I want to do something that will be usable by others. I also
favor something dead simple, so it will be implemented. If we don't
reach some sort of conclusion, this is an interesting waste of time. I
propose only people engaged in doing something along these lines get
to vote?

Tim

Re: [CODE4LIB] Twitter annotations and library software

On Thu, Apr 29, 2010 at 10:32 AM, Rosalyn Metz  wrote:
> I'm going to throw in my two cents.
>
> I dont think (and correct me if i'm wrong) we have mentioned once what
> a user might actually put in a twitter annotation.  a book title?  an
> article title? a link?

I think the idea is these would be machine generated from an
application.  So, imagine LT, Amazon, Delicious Library or SFX having
a "Tweet this!" button and *that* provides the annotation (not the
user).
>
> i think creating some super complicated thing for a twitter annotation
> dooms it to failure.  after all, its twitter...make it short and
> sweet.
>
Indeed, it's limited.

> also the 1.0 document for OpenURL isn't really that bad (yes I have
> read it).  a good portion of it is a chart with the different metadata
> elements.  also open url could conceivably refer to an animal and then
> link to a bunch of resources on that animal, but no one has done that.
>  i don't think that's a problem with OpenURL i think thats a problem
> with the metadata sent by vendors to link resolvers and librarians
> lack of creativity (yes i did make a ridiculous generalization that
> was not intended to offend anyone but inevitably it will).  having
> been a vendor who has worked with openurl, i know that the informaiton
> databases send seriously effects (affects?) what you can actually do
> in a link resolver.
>
No, this is the mythical promise of 1.0, but delivery is, frankly,
much more complicated than that.  It is impractical to expect an
OpenURL link resolver to make sense of any old thing you throw at it
and return sensible results.  This is the point of the community
profiles, to narrow the infinite possibilities a bit.  None of our
current profiles would support the scenario you speak of and I would
be surprised if such a service were to be devised, that it would be
built on OpenURL.

I think it's very easy to underestimate how complicated it is to
actually build something using OpenURL since in the abstract it seems
like a very logical solution to any problem.

-Ross.
>
>
>
>
> On Thu, Apr 29, 2010 at 10:23 AM, Tim Spalding  wrote:
>> Can we just hold a vote or something?
>>
>> I'm happy to do whatever the community here wants and will actually
>> use. I want to do something that will be usable by others. I also
>> favor something dead simple, so it will be implemented. If we don't
>> reach some sort of conclusion, this is an interesting waste of time. I
>> propose only people engaged in doing something along these lines get
>> to vote?
>>
>> Tim
>>
>

Re: [CODE4LIB] Twitter annotations and library software

2010-04-29 Thread Rosalyn Metz

I'm going to throw in my two cents.

I dont think (and correct me if i'm wrong) we have mentioned once what
a user might actually put in a twitter annotation.  a book title?  an
article title? a link?

i think creating some super complicated thing for a twitter annotation
dooms it to failure.  after all, its twitter...make it short and
sweet.

also the 1.0 document for OpenURL isn't really that bad (yes I have
read it).  a good portion of it is a chart with the different metadata
elements.  also open url could conceivably refer to an animal and then
link to a bunch of resources on that animal, but no one has done that.
 i don't think that's a problem with OpenURL i think thats a problem
with the metadata sent by vendors to link resolvers and librarians
lack of creativity (yes i did make a ridiculous generalization that
was not intended to offend anyone but inevitably it will).  having
been a vendor who has worked with openurl, i know that the informaiton
databases send seriously effects (affects?) what you can actually do
in a link resolver.

On Thu, Apr 29, 2010 at 10:23 AM, Tim Spalding  wrote:
> Can we just hold a vote or something?
>
> I'm happy to do whatever the community here wants and will actually
> use. I want to do something that will be usable by others. I also
> favor something dead simple, so it will be implemented. If we don't
> reach some sort of conclusion, this is an interesting waste of time. I
> propose only people engaged in doing something along these lines get
> to vote?
>
> Tim
>

Re: [CODE4LIB] Twitter annotations and library software

I wouldn't count on the community using anything, just because random 
people on the listserv voted on it.


If you're coding it, you should take account of the feedback, and then 
go on and create something that YOU will use, and makes sense to you.  
And then hope other people do too.  That's pretty much the best you can do.


Vote by random people on a listserv is hardly a guarantee of getting a 
standard that actually works, or that people actually use -- just look 
at OpenURL 1.0!


Tim Spalding wrote:

Can we just hold a vote or something?

I'm happy to do whatever the community here wants and will actually
use. I want to do something that will be usable by others. I also
favor something dead simple, so it will be implemented. If we don't
reach some sort of conclusion, this is an interesting waste of time. I
propose only people engaged in doing something along these lines get
to vote?

Tim

Re: [CODE4LIB] Twitter annotations and library software

2010-04-29 Thread Tim Spalding

Can we just hold a vote or something?

I'm happy to do whatever the community here wants and will actually
use. I want to do something that will be usable by others. I also
favor something dead simple, so it will be implemented. If we don't
reach some sort of conclusion, this is an interesting waste of time. I
propose only people engaged in doing something along these lines get
to vote?

Tim

Re: [CODE4LIB] Twitter annotations and library software

Yes, what MJ said is indeed exactly my perspective as well.

MJ Suhonos wrote:

It's not that it's cool to hate on OpenURL, but if you've really
worked with it it's easy to grow bitter.

Well, fair enough. Perhaps what I'm defending isn't OpenURL per se, but rather
the concept of being able to transport descriptive assertions the way the 1.0
spec proposes.

The reason that context-sensitive services based on bibliographic
citations comprise 99% of all OpenURL activity is because:
A) that was the problem it was originally designed to solve

Yes, right. And neither libraries nor vendors moved past this when 1.0 came
out for the reasons described (too complex, no immediate use cases).

The barriers to entry + the complexity of implementation almost
guarantee that there's a better or, at any rate, easier alternative to
any problem.

Let me be clear: I am *all* for a better system — even the first RSS specs were
fragmented and crappy, which led to Atom. But for the time they were around,
they were useful, if kludgy. My only point (and I think, Jonathan's) is that
OpenURL, for better or worse, *exists* and *works* now, if not ideally. If it
sucks, the onus is on us, I think, to improve it or produce something better.

The difference between OpenURL and DublinCore is that the RDF
community picked up on DC because it was simple and did exactly what
they needed (and nothing more).

Actually the difference between OpenURL and DC is that one is a transport
protocol and one is a metadata schema. :-) But I get your and Mike's point
about OpenURL 1.0 being too complicated for librarians to bother with.

All of this to support vapour use-cases that no-one has taken
advantage of because no-one ever needed to do that stuff. So the sum
achievement of OpenURL 1.0 has been (A) to fill people with fear of
what used to be a very useful and perfectly straightforward
specification, and (B) where implemented at all, to balkanise
implementations.

Sounds a lot like Z39.50, to me, actually. I guess I just see this as a classic example of
librarians (and of course I'm generalizing) sitting with a tool-in-hand and saying "this isn't
good enough", tossing it in the trash, and then lamenting the lack of tools for doing useful
things. Sort of like MODS (for those on the NGC4lib list). I know we're supposed to be
pragmatists on C4L, but do we just relegate ourselves to doing "stuff we need to do", or
pushing our existing tools to experiment?

You don't *have* to use the KEVs with OpenURL, you can use anything, including
eg. Dublin Core.

Yeah.

So long as you don't mind that only 0.01% of the world's OpenURL
resolvers will know what to do with them.

Absolutely. So how about we build some better resolvers and do useful and
interesting new things with them? Like, Twitter annotations. :-)

Re: [CODE4LIB] Twitter annotations and library software


I agree that OpenURL is crappy.

My point was that the "problem case" -- 'identifying' (or describing an 
element sufficient for identification, if you like to call it that) 
publications that do not have standard identifiers -- is a real one.  
OpenURL _does_ solve it.   You _probably_ don't want to ignore this 
problem case  in a twitter annotation scenario.  If you can solve it 
_better_ than OpenURL, than all the better. Or if you decide 
intentionally to exclude it from your scenario, that's fine, you know 
your intended domain.  

But OpenURL, despite it's crappiness, _does_ address this "problem case" 
reasonably effectively, and it is really in use.


I'm certainly not trying to be an OpenURL booster.  But it works, and 
until/unless we have something better, is is addressing a problem case 
that is really important in many scenarios (like getting users to 
licensed full text, naturally).


Jonathan

Ross Singer wrote:

On Thu, Apr 29, 2010 at 8:17 AM, MJ Suhonos  wrote:
  

Okay, I know it's cool to hate on OpenURL, but I feel I have to clarify a few 
points:




It's not that it's cool to hate on OpenURL, but if you've really
worked with it it's easy to grow bitter.


  

Maybe if I put it that way, OpenURL sounds a little less crappy.



No, OpenURL is still crappy and it will always be crappy, I'm afraid,
because it's tremendously complicated, mainly from the fact that it
tries to do too much.

The reason that context-sensitive services based on bibliographic
citations comprise 99% of all OpenURL activity is because:
A) that was the problem it was originally designed to solve
B) it's the only thing it really does well (and OpenURL 1.0's
insistence on being able to solve any problem almost takes that
strength away from it)

The barriers to entry + the complexity of implementation almost
guarantee that there's a better or, at any rate, easier alternative to
any problem.

The difference between OpenURL and DublinCore is that the RDF
community picked up on DC because it was simple and did exactly what
they needed (and nothing more).  A better analogy would be Z39.50 or
SRU: two non-library-specific protocols that, for their own reasons,
haven't seen much uptake outside of the library community.

-Ross.

Re: [CODE4LIB] Twitter annotations and library software

Let me correct myself (for the detail-oriented among us):

> Actually the difference between OpenURL and DC is that one is a transport 
> protocol and one is a metadata schema.  :-)

OpenURL is a *serialization format* which happens to be actionable by a 
transport protocol (HTTP), which is its main benefit.

Re: [CODE4LIB] Twitter annotations and library software

> It's not that it's cool to hate on OpenURL, but if you've really
> worked with it it's easy to grow bitter.

Well, fair enough.  Perhaps what I'm defending isn't OpenURL per se, but rather 
the concept of being able to transport descriptive assertions the way the 1.0 
spec proposes.

> The reason that context-sensitive services based on bibliographic
> citations comprise 99% of all OpenURL activity is because:
> A) that was the problem it was originally designed to solve

Yes, right.  And neither libraries nor vendors moved past this when 1.0 came 
out for the reasons described (too complex, no immediate use cases).

> The barriers to entry + the complexity of implementation almost
> guarantee that there's a better or, at any rate, easier alternative to
> any problem.

Let me be clear: I am *all* for a better system — even the first RSS specs were 
fragmented and crappy, which led to Atom.  But for the time they were around, 
they were useful, if kludgy.  My only point (and I think, Jonathan's) is that 
OpenURL, for better or worse, *exists* and *works* now, if not ideally.  If it 
sucks, the onus is on us, I think, to improve it or produce something better.

> The difference between OpenURL and DublinCore is that the RDF
> community picked up on DC because it was simple and did exactly what
> they needed (and nothing more).

Actually the difference between OpenURL and DC is that one is a transport 
protocol and one is a metadata schema.  :-)  But I get your and Mike's point 
about OpenURL 1.0 being too complicated for librarians to bother with.

> All of this to support vapour use-cases that no-one has taken
> advantage of because no-one ever needed to do that stuff.  So the sum
> achievement of OpenURL 1.0 has been (A) to fill people with fear of
> what used to be a very useful and perfectly straightforward
> specification, and (B) where implemented at all, to balkanise
> implementations.

Sounds a lot like Z39.50, to me, actually.  I guess I just see this as a 
classic example of librarians (and of course I'm generalizing) sitting with a 
tool-in-hand and saying "this isn't good enough", tossing it in the trash, and 
then lamenting the lack of tools for doing useful things.  Sort of like MODS 
(for those on the NGC4lib list).  I know we're supposed to be pragmatists on 
C4L, but do we just relegate ourselves to doing "stuff we need to do", or 
pushing our existing tools to experiment?

>> You don't *have* to use the KEVs with OpenURL, you can use anything, 
>> including eg. Dublin Core.
> 
> Yeah.
> 
> So long as you don't mind that only 0.01% of the world's OpenURL
> resolvers will know what to do with them.

Absolutely.  So how about we build some better resolvers and do useful and 
interesting new things with them?  Like, Twitter annotations.  :-)

MJ

Re: [CODE4LIB] Twitter annotations and library software

2010-04-29 Thread Walker, David

> We're using maybe 1% of the spec for 99% of our practice, 
> probably because librarians weren't imaginative (as Jim 
> Weinheimer would say) enough to think of other use cases 
> beyond that most pressing one.

I would suggest it's more because, once you step outside of the primary use 
case for OpenURL, you end-up bumping into *other* standards.

 Dorthea'sblog post that Jakob referenced in his message is a good example of 
that.  She was trying to use OpenURL (via COINS) to get data into Zotero.  
Mid-way through the post she wonders if maybe she should have gone with unAPI 
instead.  

And, in fact, I think that would have been a better approach.  unAPI is better 
at doing that particular task than OpenURL.  And I think that may explain why 
OpenURL hasn't become the One Standard to Rule Them All, even though it kind of 
presents itself that way.

--Dave

==
David Walker
Library Web Services Manager
California State University
http://xerxes.calstate.edu

From: Code for Libraries [code4...@listserv.nd.edu] On Behalf Of MJ Suhonos 
[...@suhonos.ca]
Sent: Thursday, April 29, 2010 5:17 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Twitter annotations and library software

Okay, I know it's cool to hate on OpenURL, but I feel I have to clarify a few 
points:

> OpenURL is of no use if you seperate it from the existing infrastructure 
> which is mainly held by companies. No sane person will try to build an open 
> alternative infrastructure because OpenURL is a crapy library-standard like 
> MARC etc.

OpenURL is mostly implemented by libraries, yes, but it isn't necessarily 
*just* a library standard - this is akin to saying that Dublin Core is a 
library standard.  Only sort of.

The other issue I have is that — although Jonathan used the term to make a 
point — OpenURL is *not* an infrastructure, it is a protocol.  Condemning the 
current OpenURL infrastructure (which is mostly a vendor-driven oligopoly) is 
akin to saying in 2004 that HTTP and HTML sucks because Firefox hadn't been 
released yet and all we had was IE6.  Don't condemn the standard because of the 
implementation.

> The OpenURL specification is a 119 page PDF - that alone is a reason to run 
> away as fast as you can.

The main reason for this is because OpenURL can do much, much, much more than 
the simple "resolve a unique copy" use case that libraries use it for.  We're 
using maybe 1% of the spec for 99% of our practice, probably because librarians 
weren't imaginative (as Jim Weinheimer would say) enough to think of other use 
cases beyond that most pressing one.

I'd contend that OpenURL, like other technologies ( XML) is greatly 
misunderstood, and therefore abused, and therefore discredited.  I think there 
is also often confusion between the KEV schemas and OpenURL itself (which is 
really what Dorothea's blog rant is about); I'm certainly guilty of this 
myself, as Jonathan can attest.

You don't *have* to use the KEVs with OpenURL, you can use anything, including 
eg. Dublin Core.

> If a twitter annotation setup wants to get adopted than it should not be 
> build on a crapy complex library standard like OpenURL.

I don't quite understand this (but I think I agree) — twitter annotation should 
be built on a data model, and then serialized via whatever protocols make sense 
(which may or may not include OpenURL).

> I must admit that this solution is based on the open assumption that CSL 
> record format contains all information needed for OpenURL which may not the 
> case.
> …

A good example.  And this is where you're exactly right that we need better 
tools, namely OpenURL resolvers which can do much more than they do now.  I've 
had the idea for a number of years now that OpenURL functionality should be 
merged into aggregation / discovery layer (eg. OAI harvester)-type systems, 
because, like OAI-PMH, OpenURL can *transport metadata*, we just don't use it 
for that in practice.

A ContextObject is just a triple that makes a single assertion about two 
entities (resources): that A "references" B.  Just like an RDF statement using 
, but with more focus on describing the 
entities rather than the assertion.

Maybe if I put it that way, OpenURL sounds a little less crappy.

MJ

Re: [CODE4LIB] Twitter annotations and library software

2010-04-29 Thread Mike Taylor

On 29 April 2010 13:17, MJ Suhonos  wrote:
>> The OpenURL specification is a 119 page PDF - that alone is a reason to run 
>> away as fast as you can.
>
> The main reason for this is because OpenURL can do much, much, much more than 
> the simple "resolve a unique copy" use case that libraries use it for.  We're 
> using maybe 1% of the spec for 99% of our practice, probably because 
> librarians weren't imaginative (as Jim Weinheimer would say) enough to think 
> of other use cases beyond that most pressing one.

It's worth contrasting this with the original OpenURL specification,
now retro-numbered as v0.1:
http://www.openurl.info/registry/docs/pdf/openurl-01.pdf
This is the one that everyone implemented in a burst of enthusiasm
earlier this decade.  You know, in the way, almost on-one's
implemented v1.0.

That document is TEN pages long.  Eight, really, since the total count
includes a page containing the foreword written after the event and a
page of acknowledgements consisting of a single 11-word sentence.

Can we be surprised that this specification attracted more interest
than the one fifteen times longer?

OpenURL 1.0 took that simple, comprehensible spec -- one that you
could read over lunch and fully understand -- and blew it up into a
super-generalised exercise in architecture astronautics.  And then
provided ANOTHER big document explaining how you can "profile" OpenURL
1.0 to make it do the stuff that v0.1 does (i.e. what you actually
WANT it to do) -- except, of course, that it expresses the same
concepts in a different way, so that v0.1 and v1.0 OpenURLs are
mutually incomprehensible.

All of this to support vapour use-cases that no-one has taken
advantage of because no-one ever needed to do that stuff.  So the sum
achievement of OpenURL 1.0 has been (A) to fill people with fear of
what used to be a very useful and perfectly straightforward
specification, and (B) where implemented at all, to balkanise
implementations.

> I'd contend that OpenURL, like other technologies ( XML) is greatly 
> misunderstood, and therefore abused, and therefore discredited.  I think 
> there is also often confusion between the KEV schemas and OpenURL itself 
> (which is really what Dorothea's blog rant is about); I'm certainly guilty of 
> this myself, as Jonathan can attest.
>
> You don't *have* to use the KEVs with OpenURL, you can use anything, 
> including eg. Dublin Core.

Yeah.

So long as you don't mind that only 0.01% of the world's OpenURL
resolvers will know what to do with them.

Re: [CODE4LIB] Twitter annotations and library software

On Thu, Apr 29, 2010 at 8:17 AM, MJ Suhonos  wrote:
> Okay, I know it's cool to hate on OpenURL, but I feel I have to clarify a few 
> points:
>

It's not that it's cool to hate on OpenURL, but if you've really
worked with it it's easy to grow bitter.

> Maybe if I put it that way, OpenURL sounds a little less crappy.

No, OpenURL is still crappy and it will always be crappy, I'm afraid,
because it's tremendously complicated, mainly from the fact that it
tries to do too much.

The reason that context-sensitive services based on bibliographic
citations comprise 99% of all OpenURL activity is because:
A) that was the problem it was originally designed to solve
B) it's the only thing it really does well (and OpenURL 1.0's
insistence on being able to solve any problem almost takes that
strength away from it)

The barriers to entry + the complexity of implementation almost
guarantee that there's a better or, at any rate, easier alternative to
any problem.

The difference between OpenURL and DublinCore is that the RDF
community picked up on DC because it was simple and did exactly what
they needed (and nothing more).  A better analogy would be Z39.50 or
SRU: two non-library-specific protocols that, for their own reasons,
haven't seen much uptake outside of the library community.

-Ross.

Re: [CODE4LIB] Twitter annotations and library software