subject:"\[CODE4LIB\] Twitter annotations and library software"

On Thu, Apr 29, 2010 at 8:17 AM, MJ Suhonos m...@suhonos.ca 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.

snip
 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

2010-04-29 Thread Mike Taylor

On 29 April 2010 13:17, MJ Suhonos m...@suhonos.ca 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 (cough 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

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 (cough 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 
http://purl.org/dc/terms/references, 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 MJ Suhonos

 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 MJ Suhonos

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


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 m...@suhonos.ca 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.

snip
  

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

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

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

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 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 t...@librarything.com 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 rosalynm...@gmail.com 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 t...@librarything.com 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 Benjamin Young

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 Spaldingt...@librarything.com  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

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 rossfsin...@gmail.com wrote:
 On Thu, Apr 29, 2010 at 10:32 AM, Rosalyn Metz rosalynm...@gmail.com 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 t...@librarything.com 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 11:21 AM, Jonathan Rochkind rochk...@jhu.edu 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 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

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. AI 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 rosalynm...@gmail.com 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 rossfsin...@gmail.com wrote:
 On Thu, Apr 29, 2010 at 10:32 AM, Rosalyn Metz rosalynm...@gmail.com 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 t...@librarything.com 
 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 Eric Hellman

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

2010-04-29 Thread Benjamin Young

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

2010-04-29 Thread Alexander Johannesen

Hi,

On Thu, Apr 29, 2010 at 22:47, Walker, David dwal...@calstate.edu 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 ---

Re: [CODE4LIB] Twitter annotations and library software

2010-04-28 Thread Ed Summers

On Tue, Apr 27, 2010 at 7:02 AM, Jakob Voss jakob.v...@gbv.de wrote:
 If you want to put bibliographic metadata
 into twitter annotations (good idea) you first need to clarify the basic
 purpose of embedding this information. I see two of them:

 I. Identification: To identify other tweets and resources that refer to the
 same publication

 II. Description: To nicely show which publication someone refers to.

I think this is right. I wonder, would you consider a potential use
case for Description to also provide machine readable data for a
resource when a standard identifier is not known?

It would be interesting to explore what identifiers + csl (and other
options) would look like in a twitter annotation if you had time to
mock something up in a wiki somewhere :-)

//Ed

[1] http://citationstyles.org/citation-style-language/schema/

Re: [CODE4LIB] Twitter annotations and library software

2010-04-28 Thread Jakob Voss


Hi

it's funny how quickly you vote against BibTeX, but at least it is a 
format that is frequently used in the wild to create citations. If you 
call BibTeX undocumented and garbage then how do you call MARC which is 
far more difficult to make use of?


My assumption was that there is a specific use case for bibliographic 
data in twitter annotations:


I. Identifiy publication = this can *only* be done seriously with 
identifiers like ISBN, DOI, OCLCNum, LCCN etc.


II. Deliver a citation = use a citation-oriented format (BibTeX, CSL, RIS)

I was not voting explicitly for BibTeX but at least there is a large 
community that can make use of it. I strongly favour CSL 
(http://citationstyles.org/) because:


- there is a JavaScript CSL-Processor. JavaScript is kind of a 
punishment but it is the natural environment for the Web 2.0 Mashup 
crowd that is going to implement applications that use Twitter annotations


- there are dozens of CSL citation styles so you can display a citation 
in any way you want


As Ross pointed out RIS would be an option too, but I miss the easy open 
source tools that use RIS to create citations from RIS data.


Any other relevant format that I know (Bibont, MODS, MARC etc.) does not 
aim at identification or citation at the first place but tries to model 
the full variety of bibliographic metadata. If your use case is


III. Provide semantic properties and connections of a publication

Then you should look at the Bibliographic Ontology. But III does *not* 
just subsume usecase II. - it is a different story that is not beeing 
told by normal people but only but metadata experts, semantic web gurus, 
library system developers etc. (I would count me to this groups). If you 
want such complex data then you should use other systems but Twitter for 
data exchange anyway.


A list of CSL metadata fields can be found at

http://citationstyles.org/downloads/specification.html#appendices

and the JavaScript-Processor (which is also used in Zotero) provides 
more information for developers: http://groups.google.com/group/citeproc-js


Cheers
Jakob

P.S: An example of a CSL record from the JavaScript client:

{
title: True Crime Radio and Listener Disenchantment with Network 
Broadcasting, 1935-1946,

  author: [ {
family: Razlogova,
given: Elena
  } ],
 container-title: American Quarterly,
 volume: 58,
 page: 137-158,
 issued: { date-parts: [ [2006, 3] ] },
 type: article-journal
}


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

2010-04-28 Thread Ed Summers

On Wed, Apr 28, 2010 at 4:17 AM, Jakob Voss jakob.v...@gbv.de wrote:
 P.S: An example of a CSL record from the JavaScript client:

 {
 title: True Crime Radio and Listener Disenchantment with Network
 Broadcasting, 1935-1946,
  author: [ {
    family: Razlogova,
    given: Elena
  } ],
  container-title: American Quarterly,
  volume: 58,
  page: 137-158,
  issued: { date-parts: [ [2006, 3] ] },
  type: article-journal
 }

This looks really nice for the Description side. Has the JSON
serialization for CSL been detailed anywhere yet?

//Ed

Re: [CODE4LIB] Twitter annotations and library software

2010-04-28 Thread Owen Stephens

We've had problems with RIS on a recent project. Although there is a
specification (http://www.refman.com/support/risformat_intro.asp), it is (I
feel) lacking enough rigour to ever be implemented consistently. The most
common issue in the wild that I've seen is use of different tags for the
same information (which the specification does not nail down enough to know
when each should be used):

Use of TI or T1 for primary title
Use of AU or A1 for primary author
Use of UR, L1 or L2 to link to 'full text'

Perhaps more significantly the specification doesn't include any field
specifically for a DOI, but despite this EndNote (owned by ISI ResearchSoft,
who are also responsible for the RIS format specification) includes the DOI
in a DO field in its RIS output - not to specification.

Owen

On Wed, Apr 28, 2010 at 9:17 AM, Jakob Voss jakob.v...@gbv.de wrote:

 Hi

 it's funny how quickly you vote against BibTeX, but at least it is a format
 that is frequently used in the wild to create citations. If you call BibTeX
 undocumented and garbage then how do you call MARC which is far more
 difficult to make use of?

 My assumption was that there is a specific use case for bibliographic data
 in twitter annotations:

 I. Identifiy publication = this can *only* be done seriously with
 identifiers like ISBN, DOI, OCLCNum, LCCN etc.

 II. Deliver a citation = use a citation-oriented format (BibTeX, CSL, RIS)

 I was not voting explicitly for BibTeX but at least there is a large
 community that can make use of it. I strongly favour CSL (
 http://citationstyles.org/) because:

 - there is a JavaScript CSL-Processor. JavaScript is kind of a punishment
 but it is the natural environment for the Web 2.0 Mashup crowd that is going
 to implement applications that use Twitter annotations

 - there are dozens of CSL citation styles so you can display a citation in
 any way you want

 As Ross pointed out RIS would be an option too, but I miss the easy open
 source tools that use RIS to create citations from RIS data.

 Any other relevant format that I know (Bibont, MODS, MARC etc.) does not
 aim at identification or citation at the first place but tries to model the
 full variety of bibliographic metadata. If your use case is

 III. Provide semantic properties and connections of a publication

 Then you should look at the Bibliographic Ontology. But III does *not*
 just subsume usecase II. - it is a different story that is not beeing told
 by normal people but only but metadata experts, semantic web gurus, library
 system developers etc. (I would count me to this groups). If you want such
 complex data then you should use other systems but Twitter for data exchange
 anyway.

 A list of CSL metadata fields can be found at

 http://citationstyles.org/downloads/specification.html#appendices

 and the JavaScript-Processor (which is also used in Zotero) provides more
 information for developers: http://groups.google.com/group/citeproc-js

 Cheers
 Jakob

 P.S: An example of a CSL record from the JavaScript client:

 {
 title: True Crime Radio and Listener Disenchantment with Network
 Broadcasting, 1935-1946,
  author: [ {
family: Razlogova,
given: Elena
  } ],
  container-title: American Quarterly,
  volume: 58,
  page: 137-158,
  issued: { date-parts: [ [2006, 3] ] },
  type: article-journal

 }


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




-- 
Owen Stephens
Owen Stephens Consulting
Web: http://www.ostephens.com
Email: o...@ostephens.com

Re: [CODE4LIB] Twitter annotations and library software

2010-04-28 Thread Jakob Voss


Ed Summers wrote:


II. Description: To nicely show which publication someone refers to.


I think this is right. I wonder, would you consider a potential use
case for Description to also provide machine readable data for a
resource when a standard identifier is not known?


There are lookup services to get a standard identifier when only some 
bibliographic data is known - mainly OpenURL. I have not investigated 
whether you can easily map CSL format to OpenURL or if you need to also 
embed the OpenURL as twitter annotation. However all lookup services 
that I know are either crapy or proprietary or both. This is not a 
technical issue but just based on a lack of data (hopefully to get 
better with more linked open data). Given enough open bibliographic data 
anyone can create a lookup service where you throw in some title, author 
and this stuff and get back an identified record. I think there also are 
some services called library catalog for this purpose.


Anyway this os nothing that can be solved with a bibliographic data 
format alone. Either you have a standard identifier or you have not. If 
you have not, you must rely on third party services that run independent 
of your bibliographic data.



It would be interesting to explore what identifiers + csl (and other
options) would look like in a twitter annotation if you had time to
mock something up in a wiki somewhere :-)


I summarized my findings on CSL at

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

and included some ideas of CSL and other data in twitter annotations. 
Feel free to modify!


Cheers
Jakob

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

2010-04-28 Thread Walker, David

I was also just working on DOI with RIS.

It looks like both Endnote and Refworks recognize 'DO' for DOIs.  But 
apparently Zotero does not.  If Zotero supported it, I'd say we'd have a de 
facto standard on our hands.

In fact, I couldn't figure out how to pass a DOI to Zotero using RIS.  Or, at 
least, in my testing I never saw the DOI show-up in Zotero.  I don't really use 
Zotero, so I may have missed it.

--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 Owen Stephens 
[o...@ostephens.com]
Sent: Wednesday, April 28, 2010 2:26 AM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] Twitter annotations and library software

We've had problems with RIS on a recent project. Although there is a
specification (http://www.refman.com/support/risformat_intro.asp), it is (I
feel) lacking enough rigour to ever be implemented consistently. The most
common issue in the wild that I've seen is use of different tags for the
same information (which the specification does not nail down enough to know
when each should be used):

Use of TI or T1 for primary title
Use of AU or A1 for primary author
Use of UR, L1 or L2 to link to 'full text'

Perhaps more significantly the specification doesn't include any field
specifically for a DOI, but despite this EndNote (owned by ISI ResearchSoft,
who are also responsible for the RIS format specification) includes the DOI
in a DO field in its RIS output - not to specification.

Owen

On Wed, Apr 28, 2010 at 9:17 AM, Jakob Voss jakob.v...@gbv.de wrote:

 Hi

 it's funny how quickly you vote against BibTeX, but at least it is a format
 that is frequently used in the wild to create citations. If you call BibTeX
 undocumented and garbage then how do you call MARC which is far more
 difficult to make use of?

 My assumption was that there is a specific use case for bibliographic data
 in twitter annotations:

 I. Identifiy publication = this can *only* be done seriously with
 identifiers like ISBN, DOI, OCLCNum, LCCN etc.

 II. Deliver a citation = use a citation-oriented format (BibTeX, CSL, RIS)

 I was not voting explicitly for BibTeX but at least there is a large
 community that can make use of it. I strongly favour CSL (
 http://citationstyles.org/) because:

 - there is a JavaScript CSL-Processor. JavaScript is kind of a punishment
 but it is the natural environment for the Web 2.0 Mashup crowd that is going
 to implement applications that use Twitter annotations

 - there are dozens of CSL citation styles so you can display a citation in
 any way you want

 As Ross pointed out RIS would be an option too, but I miss the easy open
 source tools that use RIS to create citations from RIS data.

 Any other relevant format that I know (Bibont, MODS, MARC etc.) does not
 aim at identification or citation at the first place but tries to model the
 full variety of bibliographic metadata. If your use case is

 III. Provide semantic properties and connections of a publication

 Then you should look at the Bibliographic Ontology. But III does *not*
 just subsume usecase II. - it is a different story that is not beeing told
 by normal people but only but metadata experts, semantic web gurus, library
 system developers etc. (I would count me to this groups). If you want such
 complex data then you should use other systems but Twitter for data exchange
 anyway.

 A list of CSL metadata fields can be found at

 http://citationstyles.org/downloads/specification.html#appendices

 and the JavaScript-Processor (which is also used in Zotero) provides more
 information for developers: http://groups.google.com/group/citeproc-js

 Cheers
 Jakob

 P.S: An example of a CSL record from the JavaScript client:

 {
 title: True Crime Radio and Listener Disenchantment with Network
 Broadcasting, 1935-1946,
  author: [ {
family: Razlogova,
given: Elena
  } ],
  container-title: American Quarterly,
  volume: 58,
  page: 137-158,
  issued: { date-parts: [ [2006, 3] ] },
  type: article-journal

 }


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




--
Owen Stephens
Owen Stephens Consulting
Web: http://www.ostephens.com
Email: o...@ostephens.com

Re: [CODE4LIB] Twitter annotations and library software

2010-04-28 Thread Owen Stephens

Unfortunately RefWorks only imports DO - not exports! We now recommend using
RefWorks XML when exporting (for our project) - which is fine, but not
publicly documented as far as I know :(

Zotero recommend using BibTex for importing from RefWorks I think

Owen

On Wed, Apr 28, 2010 at 2:05 PM, Walker, David dwal...@calstate.edu wrote:

 I was also just working on DOI with RIS.

 It looks like both Endnote and Refworks recognize 'DO' for DOIs.  But
 apparently Zotero does not.  If Zotero supported it, I'd say we'd have a de
 facto standard on our hands.

 In fact, I couldn't figure out how to pass a DOI to Zotero using RIS.  Or,
 at least, in my testing I never saw the DOI show-up in Zotero.  I don't
 really use Zotero, so I may have missed it.

 --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 Owen
 Stephens [o...@ostephens.com]
 Sent: Wednesday, April 28, 2010 2:26 AM
 To: CODE4LIB@LISTSERV.ND.EDU
 Subject: Re: [CODE4LIB] Twitter annotations and library software

 We've had problems with RIS on a recent project. Although there is a
 specification (http://www.refman.com/support/risformat_intro.asp), it is
 (I
 feel) lacking enough rigour to ever be implemented consistently. The most
 common issue in the wild that I've seen is use of different tags for the
 same information (which the specification does not nail down enough to know
 when each should be used):

 Use of TI or T1 for primary title
 Use of AU or A1 for primary author
 Use of UR, L1 or L2 to link to 'full text'

 Perhaps more significantly the specification doesn't include any field
 specifically for a DOI, but despite this EndNote (owned by ISI
 ResearchSoft,
 who are also responsible for the RIS format specification) includes the DOI
 in a DO field in its RIS output - not to specification.

 Owen

 On Wed, Apr 28, 2010 at 9:17 AM, Jakob Voss jakob.v...@gbv.de wrote:

  Hi
 
  it's funny how quickly you vote against BibTeX, but at least it is a
 format
  that is frequently used in the wild to create citations. If you call
 BibTeX
  undocumented and garbage then how do you call MARC which is far more
  difficult to make use of?
 
  My assumption was that there is a specific use case for bibliographic
 data
  in twitter annotations:
 
  I. Identifiy publication = this can *only* be done seriously with
  identifiers like ISBN, DOI, OCLCNum, LCCN etc.
 
  II. Deliver a citation = use a citation-oriented format (BibTeX, CSL,
 RIS)
 
  I was not voting explicitly for BibTeX but at least there is a large
  community that can make use of it. I strongly favour CSL (
  http://citationstyles.org/) because:
 
  - there is a JavaScript CSL-Processor. JavaScript is kind of a punishment
  but it is the natural environment for the Web 2.0 Mashup crowd that is
 going
  to implement applications that use Twitter annotations
 
  - there are dozens of CSL citation styles so you can display a citation
 in
  any way you want
 
  As Ross pointed out RIS would be an option too, but I miss the easy open
  source tools that use RIS to create citations from RIS data.
 
  Any other relevant format that I know (Bibont, MODS, MARC etc.) does not
  aim at identification or citation at the first place but tries to model
 the
  full variety of bibliographic metadata. If your use case is
 
  III. Provide semantic properties and connections of a publication
 
  Then you should look at the Bibliographic Ontology. But III does *not*
  just subsume usecase II. - it is a different story that is not beeing
 told
  by normal people but only but metadata experts, semantic web gurus,
 library
  system developers etc. (I would count me to this groups). If you want
 such
  complex data then you should use other systems but Twitter for data
 exchange
  anyway.
 
  A list of CSL metadata fields can be found at
 
  http://citationstyles.org/downloads/specification.html#appendices
 
  and the JavaScript-Processor (which is also used in Zotero) provides more
  information for developers: http://groups.google.com/group/citeproc-js
 
  Cheers
  Jakob
 
  P.S: An example of a CSL record from the JavaScript client:
 
  {
  title: True Crime Radio and Listener Disenchantment with Network
  Broadcasting, 1935-1946,
   author: [ {
 family: Razlogova,
 given: Elena
   } ],
   container-title: American Quarterly,
   volume: 58,
   page: 137-158,
   issued: { date-parts: [ [2006, 3] ] },
   type: article-journal
 
  }
 
 
  --
  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
 



 --
 Owen Stephens
 Owen Stephens Consulting
 Web: http://www.ostephens.com
 Email: o...@ostephens.com




-- 
Owen Stephens
Owen Stephens Consulting
Web: http://www.ostephens.com

Re: [CODE4LIB] Twitter annotations and library software

2010-04-28 Thread MJ Suhonos

 - there is a JavaScript CSL-Processor. JavaScript is kind of a punishment but 
 it is the natural environment for the Web 2.0 Mashup crowd that is going to 
 implement applications that use Twitter annotations

A quick word of caution here; we got excited about citeproc-js until learning 
that it actually requires a specific extension compiled into the Javascript 
interpreter, E4X: 
http://gsl-nagoya-u.net/http/pub/citeproc-doc.html#javascript-interpreters

This is fine and cool, but is not as widely supported as Javascript itself; eg. 
Internet Explorer, Chrome, Safari, and a number of server-side Javascript 
engines do not have E4X support:
http://en.wikipedia.org/wiki/E4x

That said, I'm very excited about CSL in general and this thread in particular 
— structured citation parsing is what I dream about at night.  Great stuff.

MJ

Re: [CODE4LIB] Twitter annotations and library software


Jakob Voss wrote:
I. Identifiy publication = this can *only* be done seriously with 
identifiers like ISBN, DOI, OCLCNum, LCCN etc.
  
Ah, but for better or for worse, that's not the world we live in. We 
have LOTS of publications that either lack such identifiers altogether, 
or where information about identifiers is not available. (Mostly the 
former). That we need to identify. This is an actual use case, you can't 
just dismiss it by saying it can't be done!


The biggest example is pretty much every scholarly journal article. (A 
significant _minority_ have DOI or pmid; the majority have neither). 

And we DO identify these articles, by a description meant to serve as 
identification, often by using OpenURL.Maybe we're not doing it 
seriously, but it's a real use case, and it's being done in the wild 
in production.


Jonathan

Re: [CODE4LIB] Twitter annotations and library software


Jakob Voss wrote:


There are lookup services to get a standard identifier when only some 
bibliographic data is known - mainly OpenURL.
A standard identifier is not always _available_ -- even if you have 
access to a service to look up standard identifiers ( a not neccesarily 
realistic expectation for real world use cases) , not every publication 
HAS a standard identifier.


Jonathan

Re: [CODE4LIB] Twitter annotations and library software

Has anyone actually gotten up a _server-side_ process that uses CSL to 
produce formatted citations?   Using the citeproc-js with a certain 
custom compiled js interpreter, or anything else?


This is what I'm interested in -- I'm not concerned with making it run 
in a browser, so custom compiled JS interpreter isn't a showstopper.  
But is still something that I'm not familiar with doing, so is going to 
take me a while to figure out how to set up.  If anyone has already set 
anything up (using citeproc-js or anything else we may not know about), 
can you let us know, and maybe share your tips/instructions/code?


Jonathan

MJ Suhonos wrote:

- there is a JavaScript CSL-Processor. JavaScript is kind of a punishment but 
it is the natural environment for the Web 2.0 Mashup crowd that is going to 
implement applications that use Twitter annotations



A quick word of caution here; we got excited about citeproc-js until learning that it 
actually requires a specific extension compiled into the Javascript interpreter, E4X: 
http://gsl-nagoya-u.net/http/pub/citeproc-doc.html#javascript-interpreters

This is fine and cool, but is not as widely supported as Javascript itself; eg. 
Internet Explorer, Chrome, Safari, and a number of server-side Javascript 
engines do not have E4X support:
http://en.wikipedia.org/wiki/E4x

That said, I'm very excited about CSL in general and this thread in particular 
— structured citation parsing is what I dream about at night.  Great stuff.

MJ

Re: [CODE4LIB] Twitter annotations and library software

2010-04-28 Thread Jakob Voss


Jonathan Rochkind wrote:


Jakob Voss wrote:
I. Identifiy publication = this can *only* be done seriously with 
identifiers like ISBN, DOI, OCLCNum, LCCN etc.
  
Ah, but for better or for worse, that's not the world we live in. We 
have LOTS of publications that either lack such identifiers altogether, 
or where information about identifiers is not available. (Mostly the 
former). That we need to identify. This is an actual use case, you can't 
just dismiss it by saying it can't be done!


Call me pedantic but if you do not have an identifier than there is no 
hope to identity the publication by means of metadata. You only 
*describe* it with metadata and use additional heuristics (mostly search 
engines) to hopefully identify the publication based on the description.


But these additional heuristics are not part of the metadta while a 
well-defined identifier implies a standard of how the identifier had 
been created and how it can be looked up.


The last hope if there is no identifier is to create one. For instance 
our library system creates internal record numbers (such as OCLC 
numbers) which can be reused. You can also define an algorithm that 
creates a hash as identifier like the bibkey I mentioned. But as long as 
there is no identifier there is no identification independent from a 
bibliographic database that already contains the record to search in.


Jakob

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