[LibX] Re: Multiple options (indexes) for type=bookmarklet

Ross Singer ross.singer at library.gatech.edu
Thu Aug 17 23:50:41 EDT 2006


Godmar,

My point is merely that designing screen scrapers for every different kind
of site is, frankly, for the birds (and a losing proposition).

However, COinS (in applications like RefBase, where's there's a natural
relationship) would be a simple, standardized way to parse the data in the
page.

I guess I didn't really make myself clear, this was a recommendation for
RefBase, not LibX (or, rather, RefBase, RefWorks, BibDesk HTML output,
etc.).

-Ross.

On 8/17/06, Godmar Back <godmar at gmail.com> wrote:
>
> A few comments:
>
> - Ross: I don't understand how COinS would come in at all. Could you
> explain?
>
> - Jake: It is already possible to define or redefine local search
> options, see for instance
> http://libx.org/libx/src/editions/showconfigfile.php?edition=bul - let
> me know if you need help with it.
> The only drawback currently is that all catalogs must use the same
> labels for the "standard options" t, jt, a, Y, etc.  However,
> additional options you define for bookmarklets may use any labels.
>
> - Jake: There was a cue on Google Book Search, but the layout has
> changed significantly so it may be broken currently. Specifically,
> which pages/where would you want to see the cue?
>
> - Jake, Richard: We'll make supporting bookmarklets with multiple
> options a priority. The radical approach would of course be to create
> a specification language that is powerful enough to express what we
> currently express in JavaScript. Then we could chuck the existing
> JavaScript classes. One could use XSL, especially with the upcoming
> switch to XML-based config files, but we would like to keep it simple
> if possible. I'm currently thinking of something like shell variables
> or macros.
>
> - Richard: That said, for refbase in the very short term we might be
> better off to just write a JavaScript class. The code was recently
> rewritten to be more object-oriented, so using JavaScript's
> inheritance mechanism adding another catalog is really only a few
> lines. I'm happy to do it if you send me a public catalog I can test
> on.
>
> - Godmar
>
> On 8/14/06, Jacob Glenn <jkglenn at umich.edu> wrote:
> > I would also like to voice support for better URL options in LibX
> > bookmarklets. In order to make LibX consistent with the search features
> > offered elsewhere on our library's website I need it to offer multiple
> > search options for our E-journals database and for Metalib quicksearch
> > sets. This requires using a different url for each search option in the
> > bookmarklet, which I don't think I can currently do. It would also be
> > really nice if I could define local search options for each catalog
> > instead of making global changes.
> >
> > I've had several people suggest adding support for Google Book Search.
> > Some books (but not all) include a link to Open WorldCat, and ISBNs will
> > work if the user has autolinking turned on, but adding a cue would be
> nice.
> >
> > Jake
> >
> > Richard Karnesky wrote:
> > >> It would also be much simpler to just nip the bud at the source and
> > >> have COinS implementations for these services.  It would be really
> > >> nice to see COinS for RefBase.
> > > We will embed COinS in the future.  This way, anyone with LibX (or
> > > other clients) can stumble onto a refbase installation at another
> > > institution, but use their preferred OpenURL provider.  (We already
> > > allow an OpenURL provider to be specified server-side in the CVS
> > > version.)
> > >
> > > However, adding a more general bookmarklet to LibX would enable a
> > > customized version of LibX to use a refbase installation as a catalog.
> > >
> > > I thus think these two features (COinS in refbase & a better
> > > "bookmarklet" for LibX) address unique concerns & both features will
> > > be useful.
> > >
> > > --Rick
> > > _______________________________________________
> > > Libx mailing list
> > > Libx at mozdev.org
> > > http://mozdev.org/mailman/listinfo/libx
> > >
> > >
> >
> > _______________________________________________
> > Libx mailing list
> > Libx at mozdev.org
> > http://mozdev.org/mailman/listinfo/libx
> >
> _______________________________________________
> Libx mailing list
> Libx at mozdev.org
> http://mozdev.org/mailman/listinfo/libx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mozdev.org/pipermail/libx/attachments/20060817/549ca834/attachment.htm


More information about the Libx mailing list