 |
 |
I still don't really see how what you're talking about would practically be accomplished. For one, to have "rft.subject", like you mention, would require using the dublincore context set. Since that wouldn't be useful on its own for the services that link resolvers currently offer, OpenURL sources (i.e. A&I database providers) would have to support SAP 2 (XML) context objects so they can pass the book/journal/patent/etc. referent metadata along with the Dublin Core referent metadata. It also becomes a POST rather than a simple link (GET). What I'm saying is it ups the requirements on all ends of the ecosystem, for what? What you're talking about would be *much* more easily implemented via SRU and CQL (or OpenSearch), anyway, since your example is really performing a search. Since OpenURL doesn't have any semblance of standardized response format, a client wouldn't know what to do with the response, anyway. -Ross. On Thu, Apr 29, 2010 at 11:29 AM, Rosalyn Metz <[log in to unmask]> 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 <[log in to unmask]> wrote: >> On Thu, Apr 29, 2010 at 10:32 AM, Rosalyn Metz <[log in to unmask]> 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 <[log in to unmask]> 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 >>>> >>> >> >