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
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 jus
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
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 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
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
***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
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
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
> 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
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 anachro
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
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
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
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
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 met
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 over
> 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
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 fo
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 source
> 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
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://b
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
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 dependenc
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
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 b
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. afte
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 pre
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 wast
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 ab
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
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 mai
> 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
> 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
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
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
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
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
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
39 matches
Mail list logo
