openSearch content type

105 views
Skip to first unread message

Frank Bennett

unread,
Aug 17, 2013, 12:16:36 PM8/17/13
to zoter...@googlegroups.com
While playing around with openSearch and the Locate Menu, I came across a law site that has this set as the type:

    application/opensearchdescription+xml

The query engine of the site doesn't turn up in the Locate Menu, which expects this instead:

   
application/x-openurl-opensearchdescription+xml

It looks like the non-x form is now officially recognized:

    http://opensearchdescription-xml.mime-application.com/

Can both forms be recognized in Zotero?

Frank

Aurimas Vinckevicius

unread,
Aug 17, 2013, 12:47:31 PM8/17/13
to zoter...@googlegroups.com

https://github.com/zotero/zotero/pull/336

--
You received this message because you are subscribed to the Google Groups "zotero-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zotero-dev+...@googlegroups.com.
To post to this group, send email to zoter...@googlegroups.com.
Visit this group at http://groups.google.com/group/zotero-dev.
For more options, visit https://groups.google.com/groups/opt_out.

Simon Kornblith

unread,
Aug 17, 2013, 1:44:18 PM8/17/13
to zoter...@googlegroups.com, aurim...@gmail.com
To clarify, the reason we only accepted application/x-openurl-opensearchdescription+xml is that most standard OpenSearch engines only support searching for a single string, which is not really great for looking up many bibliographic resources. The idea was to distinguish locate engines that can make use of OpenURL metadata from plain old text search engines. Since I don't think anyone has actually created a locate engine that uses OpenURL metadata besides the ones we supply with Zotero, I think it's probably a good idea to let people add standard OpenSearch engines too, but we should think about what query to use.

Simon

Frank Bennett

unread,
Aug 17, 2013, 7:21:20 PM8/17/13
to zoter...@googlegroups.com
On Sun, Aug 18, 2013 at 2:44 AM, Simon Kornblith <si...@simonster.com> wrote:
> To clarify, the reason we only accepted
> application/x-openurl-opensearchdescription+xml is that most standard
> OpenSearch engines only support searching for a single string, which is not
> really great for looking up many bibliographic resources. The idea was to
> distinguish locate engines that can make use of OpenURL metadata from plain
> old text search engines. Since I don't think anyone has actually created a
> locate engine that uses OpenURL metadata besides the ones we supply with
> Zotero, I think it's probably a good idea to let people add standard
> OpenSearch engines too, but we should think about what query to use.
>
> Simon

Ah, I get it now. The site I was looking at is offering this, which is
indeed an openSearch endpoint that recognizes only a simple string:

https://www.courtlistener.com/static/xml/opensearch.xml

The team behind the CourtListener site have produced a text scraper
that extracts citation metadata from law cases, and it's likely that
they will offer searches based on openURL metadata at some point, to
close the loop. I'll liaise with the maintainers.

This was prompted in part by the prospect of meeting Dan Chudnov
locally at the end of this month, and I'm glad that I now know the
difference between openSearch and openURL!

Frank

gra...@gmx.com

unread,
Aug 21, 2013, 9:13:12 PM8/21/13
to zoter...@googlegroups.com
Simon wrote : "Since I don't think anyone has actually created a locate engine that uses OpenURL metadata besides the ones we supply with Zotero".

FWIW, I had created such an engine in order to access to the online version of journal articles on the publisher website (a famous french legal publisher) with the metadata provided by another website. This would have been absolutely great if the publisher 1) had not changed its website so often (thus breaking their so-called permalinks!) ; 2) had offered a PDF version of the articles with the original page-numbering, and not a poorly-edited HTML version…

G.
Reply all
Reply to author
Forward
0 new messages