On Mon, May 3, 2010 at 9:14 PM, stuart yeates wrote:
> Bill Dueber wrote:
>
>> "if the librarians would grow a pair
>> and demand better data via our contracts"
>
> While I agree with your overall point, it would have been better made with
> the gendered phrasing, in my view.
I agree, and I apolo
Bill Dueber wrote:
"if the librarians would grow a pair
and demand better data via our contracts"
While I agree with your overall point, it would have been better made
with the gendered phrasing, in my view.
cheers
stuart
--
Stuart Yeates
http://www.nzetc.org/ New Zealand Electronic T
On Mon, May 3, 2010 at 6:34 PM, Karen Coyle wrote:
> Quoting Jakob Voss :
>
>> I bet there are several reasons why OpenURL failed in some way but I
>> think one reason is that SFX got sold to Ex Libris. Afterwards there
>> was no interest of Ex Libris to get a simple clean standard and most
>> lib
Quoting Jakob Voss :
I bet there are several reasons why OpenURL failed in some way but I
think one reason is that SFX got sold to Ex Libris. Afterwards there
was no interest of Ex Libris to get a simple clean standard and most
libraries ended up in buying a black box with an OpenURL label on it
Karen Coyle wrote:
It's a shame. I can see the reasons why the committee took it the way
they did, but the whole exercise has ended up smelling of architecture
astronautics. See this column if you're not familiar with the term,
it's a good read:
http://www.joelonsoftware.com/articles/f
Here is the API response Umlaut provides to OpenURL requests with
standard scholarly formats. This API response is of course to some
extent customized to Umlaut's particular context/use cases, it was not
neccesarily intended to be any kind of standard -- certainly not with as
wide-ranging inte
I'll try to find out.
Sent from Eric Hellman's iPhone
On May 2, 2010, at 4:10 PM, stuart yeates
wrote:
But the interesting use case isn't OpenURL over HTTP, the
interesting use case (for me) is OpenURL on a disconnected eBook
reader resolving references from one ePub to other ePub cont
Ross Singer wrote:
On Fri, Apr 30, 2010 at 11:52 AM, Mike Taylor wrote:
On 30 April 2010 16:42, Ed Summers wrote:
On Fri, Apr 30, 2010 at 11:33 AM, Ross Singer wrote:
Just to clarify -- OpenURL 1.0 does not assume HTTP is being used.
Oh, so that's the problem!
Yes! Exactly!
Poor old Ope
Quoting Mike Taylor :
It's a shame. I can see the reasons why the committee took it the way
they did, but the whole exercise has ended up smelling of architecture
astronautics. See this column if you're not familiar with the term,
it's a good read:
http://www.joelonsoftware.com/artic
COinS showed that is in fact possible to do so- there are probably more COinS
in the wild than OpenURLs.
I was thinking more along the lines of Ed's suggestion, (request headers, too)
although I previously had implemented something along the lines of what Ross
suggested.
On Apr 30, 2010, at 11
> Well, that's what the "Community Profiles" are. So now you have TWO
> long, dense, boring documents to read -- the standard and the profile!
>
> The main game in town for Making OpenURL 1.0 Usable (maybe still the
> only game, come to think of it) is the San Antonio Profile, or SAP for
> short,
On 30 April 2010 16:56, Ross Singer wrote:
> On Fri, Apr 30, 2010 at 11:52 AM, Mike Taylor wrote:
>> On 30 April 2010 16:42, Ed Summers wrote:
>>> On Fri, Apr 30, 2010 at 11:33 AM, Ross Singer wrote:
Just to clarify -- OpenURL 1.0 does not assume HTTP is being used.
>>>
>>> Oh, so that's t
On Fri, Apr 30, 2010 at 11:52 AM, Mike Taylor wrote:
> On 30 April 2010 16:42, Ed Summers wrote:
>> On Fri, Apr 30, 2010 at 11:33 AM, Ross Singer wrote:
>>> Just to clarify -- OpenURL 1.0 does not assume HTTP is being used.
>>
>> Oh, so that's the problem!
>
> Yes! Exactly!
>
> Poor old OpenURL
On 30 April 2010 16:42, Ed Summers wrote:
> On Fri, Apr 30, 2010 at 11:33 AM, Ross Singer wrote:
>> Just to clarify -- OpenURL 1.0 does not assume HTTP is being used.
>
> Oh, so that's the problem!
Yes! Exactly!
Poor old OpenURL 1.0 is abstracted to hell and back. The sad old
thing doesn't ev
On Fri, Apr 30, 2010 at 11:33 AM, Ross Singer wrote:
> Just to clarify -- OpenURL 1.0 does not assume HTTP is being used.
Oh, so that's the problem!
On Fri, Apr 30, 2010 at 11:21 AM, Ed Summers wrote:
>
> I doubt I understand the full scope of the problem (never made it
> through the spec myself). But I imagine a sensible use of HTTP status
> codes would've gotten most of the way there.
Just to clarify -- OpenURL 1.0 does not assume HTTP is b
On Fri, Apr 30, 2010 at 10:43 AM, Eric Hellman wrote:
> Eek. I was hoping for something much simpler. Do you realize that you're
> asking for service taxonomy?
I doubt I understand the full scope of the problem (never made it
through the spec myself). But I imagine a sensible use of HTTP status
On Fri, Apr 30, 2010 at 10:43 AM, Eric Hellman wrote:
> Eek. I was hoping for something much simpler. Do you realize that you're
> asking for service taxonomy?
>
Yes. I think you'd have to have one, otherwise how would you know
what to expect from the results? If the target only offered TOCs o
Eek. I was hoping for something much simpler. Do you realize that you're asking
for service taxonomy?
On Apr 30, 2010, at 10:22 AM, Ross Singer wrote:
> I think the basis of a response could actually be another context
> object with the 'services' entity containing a list of
> services/targets t
Hi All,
Though hesitant to jump in here, I agree with Owen that the dead ends
aren't a standards issue. The bloat of the standard is, as is the lack
of a standardized response format, but the dead ends have to do with bad
metadata being coded into open-URLs and with breakdowns in the
connecti
On Fri, Apr 30, 2010 at 10:08 AM, Eric Hellman wrote:
> OK, what does the EdSuRoSi spec for OpenURL responses say?
>
Well, I don't think it's up to us and I think it's dependent upon
community profile (more than Z39.88 itself), since it would be heavily
influenced with what is actually trying to b
Although part of the problem is that you might want to offer any service on
the basis of an OpenURL the major use case is supply of a document (either
online or via ILL) - so it strikes me you could look at DAIA
http://www.gbv.de/wikis/cls/DAIA_-_Document_Availability_Information_API ?
Jakob does t
OK, what does the EdSuRoSi spec for OpenURL responses say?
Eric
On Apr 30, 2010, at 9:40 AM, Ed Summers wrote:
> On Fri, Apr 30, 2010 at 9:09 AM, Ross Singer wrote:
>> I actually think this lack of any specified response format is a large
>> factor in the stagnation of OpenURL as a technology.
On Fri, Apr 30, 2010 at 9:09 AM, Ross Singer wrote:
> I actually think this lack of any specified response format is a large
> factor in the stagnation of OpenURL as a technology. Since a resolver
> is under no obligation to do anything but present a web page it's
> difficult for local entreprene
On Fri, Apr 30, 2010 at 7:59 AM, Kyle Banerjee wrote:
> An obvious thing for a resolver to be able to do is return results in JSON
> so the OpenURL can be more than a static link. But since the standard
> defines no such response, the site generating the OpenURL would have to know
> something abo
On Fri, Apr 30, 2010 at 4:09 AM, Jakob Voss wrote:
> Am I right that neither OpenURL nor COinS strictly defines a metadata model
> with a set of entities/attributes/fields/you-name-it and their definition?
> Apparently all ContextObjects metadata formats are based on non-normative
> "implementati
> Dead ends from OpenURL enabled hyperlinks aren't a result of the standard
> though, but rather an aspect of both the problem they are trying to solve,
> and the conceptual way they try to do this.
>
> I'd content these dead ends are an implementation issue.
Absolutely. There is no inherent reas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Jakob Voss schrieb:
...
> Am I right that neither OpenURL nor COinS strictly defines a metadata
> model with a set of entities/attributes/fields/you-name-it and their
> definition? Apparently all ContextObjects metadata formats are based on
> non
Dead ends from OpenURL enabled hyperlinks aren't a result of the standard
though, but rather an aspect of both the problem they are trying to solve,
and the conceptual way they try to do this.
I'd content these dead ends are an implementation issue - and despite this I
have to say that my experien
Stuart Yeates wrote:
A great deal of heat has been vented in this thread, and at least a
little light.
I'd like to invite everyone to contribute to the wikipedia page at
http://en.wikipedia.org/wiki/OpenURL in the hopes that it evolves into a
better overview of the protocol, the ecosystem an
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
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
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
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
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
44 matches
Mail list logo
