Jonathan Rochkind wrote:
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
All,
The open-source Variations project (http://variations.sourceforge.net), based
at Indiana University, is planning to add streaming video to its existing
capabilities. The purpose of this survey is to learn more about academic
libraries’ needs and existing practices (if any) for delivery of
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
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,
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
Even the best standard in the world can only do so much!
On Apr 29, 2010, at 1:14 PM, Ed Summers wrote:
On Thu, Apr 29, 2010 at 12:08 PM, Eric Hellman e...@hellman.net wrote:
Since this thread has turned into a discussion on OpenURL...
I have to say that during the OpenURL 1.0
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
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
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
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
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
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
***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.
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
On Fri, Apr 30, 2010 at 04:17, Jakob Voss jakob.v...@gbv.de wrote:
But all the flaws of XML can be traced back to SGML which is why we now use
JSON despite all of its limitations.
Hmm, this is wrong on so many levels. First, SGML was pretty darn good
for its *purpose*, but it was a geeks dream
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
On Fri, Apr 30, 2010 at 10:54, Eric Hellman e...@hellman.net wrote:
May I just add here that of all the things we've talked about in these
threads, perhaps the only thing that will still be in use a hundred years
from now will be Unicode. إن شاء الله
May I remind you that we're still using
Ha!
One of the things OpenURL 1.0 fixed was to wire in UTF-8 encoding. Much of
the MARC data in circulation also uses UTF-8 encoding. Some of it even uses it
correctly.
On Apr 29, 2010, at 8:58 PM, Alexander Johannesen wrote:
On Fri, Apr 30, 2010 at 10:54, Eric Hellman e...@hellman.net
Eric Hellman wrote:
May I just add here that of all the things we've talked about in
these threads, perhaps the only thing that will still be in use a
hundred years from now will be Unicode. إن شاء الله
Sadly, yes, I agree with you on this.
Do you have any idea how demotivating that is for
37 matches
Mail list logo
