Pubget Zotero Feature - Article Lookup Platform
Cameron Allen
Last week we released a patch that provides users quick and simple
article lookup on Pubget.com (found here:
http://groups.google.com/group/zotero-dev/msg/6e1fd1c121487128?pli=1).
After brainstorming a bit with Sean and Trevor at Zotero, we'd like to
open up this feature to any service that can perform an article
lookup.
The end goal of this project would be to create a "Locate" dropdown
that could be populated with all of the user's favorite lookup
services. A preference page would allow for configuration of which
items appear on the dropdown.
The development team here at Pubget is ready to go but we were hoping
to get some feedback first. Are there any code examples of this type
of feature already implemented in the Zotero source, specifically in
regards to the preference pane and how it connects the back end to the
front end? Any input on this would be greatly appeciated.
Thanks!
Cameron Allen
te...@pubget.com
Bruce D'Arcus
On Wed, Jul 28, 2010 at 12:51 PM, Cameron Allen
<cameron...@gmail.com> wrote:
...
> The end goal of this project would be to create a "Locate" dropdown
> that could be populated with all of the user's favorite lookup
> services. A preference page would allow for configuration of which
> items appear on the dropdown.
+1
Bruce
Dan Stillman
> The development team here at Pubget is ready to go but we were hoping
> to get some feedback first. Are there any code examples of this type
> of feature already implemented in the Zotero source, specifically in
> regards to the preference pane and how it connects the back end to the
> front end? Any input on this would be greatly appeciated.
Rather than a preference pane, a better model is probably the extensible
search engine support in Firefox, where the management interface is
accessed via an option at the bottom of the menu itself. We've actually
talked in the past about using OpenSearch (which is what Firefox uses)
for the Locate menu (and possibly piggybacking on Firefox's own support
in some way), but I haven't sufficiently studied OpenSearch or thought
about what the needs would be in Zotero to know if that actually make
sense�it's possible most of the services for Zotero would need more
flexibility than OpenSearch allows. But for security reasons among
others, it's worth considering if this can be done via XML templates
(OpenSearch or otherwise) rather than code. Maybe not, but if JS is
necessary then we need to be a little more careful. (Zotero "plugins"
are code, but since those are just Firefox extensions the burden is on
Firefox to warn the user appropriately.)
mike
I work at Pubget with Cameron, and I was wondering if you could
elaborate on how OpenSearch could be used? I read up on it and it
seems like its purpose is primarily for standardizing the return
format of search results. Since this button is for linking users out
to 3rd party services, I'm not sure I understand how this would be
relevant to our use case. We're keen to start developing this
functionality, what should we do to move forward with the overarching
implementation strategy (OpenSearch vs. pref pane/etc)?
Cheers,
Mike Anderson
mi...@pubget.com
On Jul 29, 1:12 am, Dan Stillman <dstill...@zotero.org> wrote:
> On 7/28/10 12:51 PM, Cameron Allen wrote:
>
> > The development team here at Pubget is ready to go but we were hoping
> > to get some feedback first. Are there any code examples of this type
> > of feature already implemented in the Zotero source, specifically in
> > regards to the preference pane and how it connects the back end to the
> > front end? Any input on this would be greatly appeciated.
>
> Rather than a preference pane, a better model is probably the extensible
> search engine support in Firefox, where the management interface is
> accessed via an option at the bottom of the menu itself. We've actually
> talked in the past about using OpenSearch (which is what Firefox uses)
> for the Locate menu (and possibly piggybacking on Firefox's own support
> in some way), but I haven't sufficiently studied OpenSearch or thought
> about what the needs would be in Zotero to know if that actually make
Dan Stillman
> Hi Dan,
>
> I work at Pubget with Cameron, and I was wondering if you could
> elaborate on how OpenSearch could be used? I read up on it and it
> seems like its purpose is primarily for standardizing the return
> format of search results. Since this button is for linking users out
> to 3rd party services, I'm not sure I understand how this would be
> relevant to our use case. We're keen to start developing this
> functionality, what should we do to move forward with the overarching
> implementation strategy (OpenSearch vs. pref pane/etc)?
OpenSearch is used by Firefox for its extensible search engine
support�the description files (sometimes called "search plugins") tell
Firefox how to form queries for different sites. Again, see "Manage
Search Engines..." in Firefox's search bar menu for an example. Do a
curl -L on any of the "Add to Firefox" links to see the OpenSearch
description files.
The main problem with using OpenSearch for Zotero is that it's generally
limited to a simple string for search terms, whereas for many services
Zotero probably needs to do more complex queries involving multiple
fields. There's a Parameter element in OpenSearch, but most existing
search plugins are designed for single-field searches.
So I could see a few options (with the caveat that I haven't spent very
long time studying the OpenSearch spec):
1) Allow the use of Firefox's built-in OpenSearch support with existing
search plugins by providing a way for users and/or Zotero developers to
specify rules for transforming Zotero items into the {searchTerms}
OpenSearch values. This way Locate could support all existing
single-field search plugins, allowing a user to, say, create a Locate
service that performed Google searches for items by using the Zotero
item title as the {searchTerms} value. In the case of PubGet, you'd
build up an appropriate {searchTerms} value and then parse it out on
your end. This would be a bit of a hack, though.
2) Allow providers such as PubGet with more complex search capabilities
to offer OpenSearch description files that map Zotero fields to
Parameter elements. This might require Zotero to parse OpenSearch
description documents rather than Firefox, since I imagine Firefox
supports only single-field searches that use {searchTerms}. But since
Zotero supports OpenURL, this could pretty easily be implemented as an
independent JS module that took an OpenSearch description document and
an OpenURL URL as input and returned a search URL, which would allow it
to be used in other projects that can generate OpenURL. (This is
assuming that OpenURL supports all the fields we'd want. If not, we'd
need a different data input format.) If PubMed wanted to work on such a
module, we could probably help out on the Zotero side of things (and
possibly use built-in support for parsing out the icon, title, etc.).
3) Support OpenURL server-side on PubGet (if you don't already) and add
multiple-resolver support to Zotero. The main problem with this is that
it'd require server-side support (or a third-party redirector) for any
service that didn't already offer OpenURL support.
4) Define some other custom template system to do this.
5) Figure out a way to safely use JavaScript for Locate plugins. This
would come with some infrastructure and administration issues that would
be nice to avoid�and I suspect JS isn't necessary for this.
Of these options, I rather like #2, which seems it would have the
farthest-reaching benefits. The main issues I see with #2:
i) It'd be nice to use existing search plugins as well, so even if we
went with #2 we could still offer mapping support for single-field
plugins as I describe in #1. Maybe the module could take OpenURL,
OpenSearch, and an optional mapping of the OpenURL fields into
{searchTerms} (passed as a string) for use with existing search plugins?
ii) Simon notes that there might be different requirements by item type.
So we might need to be able to specify on the Zotero side that certain
description documents are to be used with certain item types. This
wouldn't affect the independent module, in any case.
Thoughts on the above?
- Dan
Cameron Allen
I've been looking over the documentation for OpenSearch, specifically
its implementation in Firefox, and I agree that it would be a good
platform for article lookup. The OpenSearch param element should allow
us to pass the necessary metadata and using this with the OpenURL spec
for parameters would provide a solid template for adding other article
lookup services.
An approach based off your #2 option seems to be the best solution.
Provided we can tap into firefox's OpenSearch support, I think this
will keep development time to a minimum while still creating a
configurable Locate dropdown that other services can easily offer
support for. We'll get started with code for this.
Thanks,
Cameron
On Aug 9, 4:07 pm, Dan Stillman <dstill...@zotero.org> wrote:
> On 8/5/10 4:31 PM, mike wrote:
>
> > Hi Dan,
>
> > I work at Pubget with Cameron, and I was wondering if you could
> > elaborate on how OpenSearch could be used? I read up on it and it
> > seems like its purpose is primarily for standardizing the return
> > format of search results. Since this button is for linking users out
> > to 3rd party services, I'm not sure I understand how this would be
> > relevant to our use case. We're keen to start developing this
> > functionality, what should we do to move forward with the overarching
> > implementation strategy (OpenSearch vs. pref pane/etc)?
>
> OpenSearch is used by Firefox for its extensible search engine
> Of these options, I rather like #2, which seems it would have the
> farthest-reaching benefits. The main issues I see with #2:
>
> i) It'd be nice to use existing search plugins as well, so even if we
> went with #2 we could still offer mapping support for single-field
> plugins as I describe in #1. Maybe the module could take OpenURL,
> OpenSearch, and an optional mapping of the OpenURL fields into
> {searchTerms} (passed as a string) for use with existing search plugins?
>
> ii) Simon notes that there might be different requirements by item type.
> So we might need to be able to specify on the Zotero side that certain
> description documents are to be used with certain item types. This
> wouldn't affect the independent module, in any case.
>
> Thoughts on the above?
>
> - Dan
>
>
>
> > Cheers,
> > Mike Anderson
Dan Stillman
Great. I'll note again that I haven't checked whether Firefox's
OpenSearch support handles the param element, so if not you may need to
reimplement the OpenSearch parsing, but I doubt that would be too difficult.
The other advantage to reimplementing parsing would be that the module
would be more useful outside of Zotero�in fact, from the perspective of
reusability, the module itself ideally wouldn't use any privileged
Firefox calls at all. But it's your dime, so this is of course up to
you. And it could also be generalized later on if someone were
interested. But whether or not you make it Firefox-dependent, I'd still
recommend keeping the module isolated from Zotero.
Thanks again for working on this. Let us know if we can help out in any way.
- Dan