<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Search on Crossref</title><link>https://www-crossref-org.pluma.sjfc.edu/categories/search/</link><description>Recent content in Search on Crossref</description><generator>Hugo 0.139.4</generator><language>en-us</language><managingEditor>support@crossref.org (Crossref/Cazinc/Benoît Benedetti)</managingEditor><webMaster>support@crossref.org (Crossref/Cazinc/Benoît Benedetti)</webMaster><lastBuildDate>Wed, 25 Jan 2023 00:00:00 +0000</lastBuildDate><atom:link href="https://www-crossref-org.pluma.sjfc.edu/categories/search/" rel="self" type="application/rss+xml"/><item><title>Measuring Metadata Impacts: Books Discoverability in Google Scholar</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/measuring-metadata-impacts-books-discoverability-in-google-scholar/</link><pubDate>Wed, 25 Jan 2023 00:00:00 +0000</pubDate><author>Lettie Conrad</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/measuring-metadata-impacts-books-discoverability-in-google-scholar/</guid><description>&lt;p>&lt;em>This blog post is from Lettie Conrad and Michelle Urberg, cross-posted from the The Scholarly Kitchen.&lt;br>
As sponsors of this project, we at Crossref are excited to see this work shared out.&lt;/em>&lt;/p>
&lt;p>The scholarly publishing community talks a LOT about metadata and the need for high-quality, interoperable, and machine-readable descriptors of the content we disseminate. However, as &lt;a href="https://scholarlykitchen.sspnet.org/2021/09/30/the-experience-of-good-metadata-linking-metadata-to-research-impacts/" target="_blank">we’ve reflected on previously in the &lt;em>Kitchen&lt;/em>&lt;/a>, despite well-established information standards (e.g., persistent identifiers), our industry lacks a shared framework to measure the value and impact of the metadata we produce.&lt;/p>
&lt;p>In 2021, we embarked on a &lt;a href="https://doi-org.pluma.sjfc.edu/10.64000/h3w86-2z708" target="_blank">Crossref-sponsored study&lt;/a> designed to measure how metadata impacts end-user experiences and contributes to the successful discovery of academic and research literature via the mainstream web. Specifically, we set out to learn if scholarly books with DOIs (and associated metadata) were more easily found in Google Scholar than those without DOIs.&lt;/p>
&lt;p>Initial results indicated that &lt;strong>DOIs have an indirect influence on the discoverability of scholarly books in Google Scholar&lt;/strong> &amp;ndash; however, we found no direct linkage between book DOIs and the quality of Google Scholar indexing or users’ ability to access the full text via search-result links. Although Google Scholar claims to not use DOI metadata in its search index, the results of our mixed-methods study of 100+ books (from 20 publishers) demonstrate that books with DOIs are generally more discoverable than those without DOIs.&lt;/p>
&lt;p>As we finalize our analysis, we are &lt;a href="https://community-crossref-org.pluma.sjfc.edu/t/with-or-without-measuring-impacts-of-books-metadata/3058" target="_blank">sharing some early results&lt;/a> and inviting input from our community. What relevant lessons can we glean from this exercise? What changes might book publishers consider based on the outcomes of this study?&lt;/p>
&lt;h2 id="background-on-the-study">Background on the study&lt;/h2>
&lt;p>This study was designed to evaluate metadata impacts &amp;amp; benefits to users. Given its popularity with a range of stakeholders in our industry, we set out to measure metadata impacts on discoverability in the mainstream web – namely, Google Scholar.&lt;/p>
&lt;p>Our test method and analysis rubric was developed based on our own information-user research, in particular how readers search and retrieve scholarly ebooks, as well as published studies about academic information experiences and research practices. We rated the search performance of more than 100 scholarly books using preset test queries (two for each title). The books tested in this study came from publishers of all sorts and sizes, and represent both monographs and edited volumes from a range of fields; some were open access and others were published under traditional licensing models.&lt;/p>
&lt;p>We developed and executed known-item test searches that were designed to simulate common researcher practices. Heuristic analysis of the search results was used to rate the search performance on a 5-point scoring rubric, which was designed to measure the degree of friction in locating the book in question. This method allowed us to assess specific book and metadata attributes by their search performance scores to assess the impact of book metadata on content discoverability in Google Scholar.&lt;/p>
&lt;h2 id="results-and-findings">Results and findings&lt;/h2>
&lt;p>In this study, we learned that high-value fields include the primary title paired with subtitles, author/editor surnames and/or field of study. Queries using full book titles performed the best across the board. Those using publication dates and/or author/editor surnames and/or publisher names, but without the book title, were the lowest performers.&lt;/p>
&lt;p>Surprisingly, our discoverability scores show no significant variation in performance by the type of book, whether edited or authored. Open-access titles performed somewhat better than traditional ones. Books covering humanities and social science fields performed a bit better than STM books, but only by a slim difference (that is not statistically significant).&lt;/p>
&lt;p>We primarily tested the discoverability of book titles, from equal numbers of books with and without chapter-level DOIs. We ran similar tests for chapter-title discoverability but found the majority of test queries for chapters lead users to the full book itself. While books without title-level DOIs were found to be less discoverable, we did not find a measurable difference between books with or without chapter-level DOIs. (Note: All books in this study with chapter-level DOIs assigned also carried a title-level DOI, which was found to be fairly common.)&lt;/p>
&lt;p>Based on these results, we are developing a theory that &lt;strong>books with DOIs perform better in Google Scholar because they benefit from the structured, open metadata associated&lt;/strong> with those DOIs – which are used by hundreds of platforms and services, and therefore are “seeded” throughout the mainstream web, which Scholar may draw on for indexing, linking, etc. That said, however, these results also suggest that publishers are best served by a metadata strategy that is well attuned to the protocols expected of each channel for book search and discovery. In a recent conversation about our findings, Anurag Acharya himself noted that these results underscore the need for publishers to invest in the robust construction and broad distribution of book metadata.&lt;/p>
&lt;p>In this study, we have observed that the metadata protocols surrounding Google Scholar are not fully integrated into our industry’s established scholarly information standards bodies, like NISO, or infrastructure organisations, like Crossref. While some mainstream data standards prevail in the Scholar index, like the use of schema.org and HTTP, some key metadata attributes seem to be lacking. For example, an indicator of the type of scholarly book (monograph, handbook, etc.) would improve Google Scholar’s search index and could be used to filter search results, thereby improving users’ experiences discovering scholarly books. One clear challenge for book publishers today is the fact that Google Scholar operates outside of our community-governed scholarly information infrastructure.&lt;/p>
&lt;h2 id="what-comes-next">What comes next&lt;/h2>
&lt;p>While this study focused on Google Scholar, the results and lessons learned are applicable to other mainstream channels of information seeking/discovery. Our report, due out spring 2023, will contribute to the literature intended to support user-centric information systems design and content architecture by scholarly publishers and service providers.&lt;/p>
&lt;p>As we write up our findings, we intend to develop a framework that can help publishers and others measure the impact of their work to enrich and distribute scholarly metadata. We hope this first systematic review of the impacts of metadata on the discoverability of books in Google Scholar will provide valuable insights for this community. In the meantime, please share your thoughts and questions in the comments below &amp;ndash; or reach out to us directly (&lt;a href="https://www.linkedin.com/in/lettieyconrad/" target="_blank">see Lettie’s profile here&lt;/a> and &lt;a href="https://www.linkedin.com/in/michelleurberg/" target="_blank">Michelle’s profile here&lt;/a>).&lt;/p>
&lt;p>Acknowledgments: &lt;em>The authors would like to thank Jennifer Kemp at Crossref for the inspiration to take this dive into the metadata literature and reflect on its impact on research information experiences. Special thanks to Anurag Acharya at Google Scholar for his consultation during this study.&lt;/em>&lt;/p></description></item><item><title>Easily add publications to your ORCID profile</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/easily-add-publications-to-your-orcid-profile/</link><pubDate>Thu, 24 Jan 2013 00:00:00 +0000</pubDate><author>Geoffrey Bilder</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/easily-add-publications-to-your-orcid-profile/</guid><description>&lt;p>&lt;span >You can now easily search for publications and add them to your &lt;a href="http://www.orcid.org" target="_blank">ORCID&lt;/a> profile in the new beta of &lt;a href="https://web.archive.org/web/20131229210637/http://search.crossref.org.pluma.sjfc.edu/" target="_blank">Crossref Metadata Search&lt;/a> (CRMDS). The user interface is pretty self-explanatory, but if you want to read about it before trying it, here is a summary of how it works.&lt;/span>&lt;/p>
&lt;p>&lt;span >When you go to to CRMDS, you will see that there is now a small ORCID sign-in button on the top right-hand side of the screen.&lt;/span>&lt;figure id="attachment_244" class="wp-caption aligncenter">&lt;/p>
&lt;p>&lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/easily-add-publications-to-your-orcid-profile/" target="_blank" rel="attachment wp-att-244">&lt;img class="size-medium wp-image-244 " src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/crmds_home-300x253.png" alt="crmds_home" width="300" height="253" srcset="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/crmds_home-300x253.png 300w, https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/crmds_home-624x527.png 624w, https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/crmds_home.png 859w" sizes="(max-width: 300px) 85vw, 300px" />&lt;/a>&lt;figcaption class="wp-caption-text">click on thumbnail to see larger image&lt;/figcaption>&lt;/figure>&lt;/p>
&lt;p>&lt;span >Clicking on this button allows you to connect CRMDS to your ORCID profile and authorises CRMDS to add publications to your profile. First, if you are not already logged into ORCID, CRMDS will ask ORCID to log you in:&lt;/span>&lt;figure id="attachment_245" class="wp-caption aligncenter">&lt;/p>
&lt;p>&lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/easily-add-publications-to-your-orcid-profile/" rel="attachment wp-att-245">&lt;img class="size-medium wp-image-245 " src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/orcid_login_prompt-300x230.png" alt="orcid_login_prompt" width="300" height="230" srcset="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/orcid_login_prompt-300x230.png 300w, https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/orcid_login_prompt-624x479.png 624w, https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/orcid_login_prompt.png 915w" sizes="(max-width: 300px) 85vw, 300px" />&lt;/a>&lt;figcaption class="wp-caption-text">click on thumbnail to see larger image&lt;/figcaption>&lt;/figure>&lt;/p>
&lt;p>&lt;span >Once you have logged in, ORCID will ask you if you want to allow CRMDS to be able to view and update your ORCID profile:&lt;/span>&lt;figure id="attachment_248" class="wp-caption aligncenter">&lt;/p>
&lt;p>&lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/easily-add-publications-to-your-orcid-profile/" target="_blank" rel="attachment wp-att-248">&lt;img class="size-medium wp-image-248 " src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/orcid_authorize-300x230.png" alt="orcid_authorize" width="300" height="230" srcset="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/orcid_authorize-300x230.png 300w, https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/orcid_authorize-624x480.png 624w, https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/orcid_authorize.png 925w" sizes="(max-width: 300px) 85vw, 300px" />&lt;/a>&lt;figcaption class="wp-caption-text">click on thumbnail to see larger image&lt;/figcaption>&lt;/figure>&lt;/p>
&lt;p>&lt;span >After you authorise CRMDS to access your profile, you will be returned to the CRMDS screen and the top right corner of the CRMDS page will indicate that you have connected to your ORCID profile (note, you can always de-authorise CRMDS from accessing your ORCID profile in your ORCID settings):&lt;/span>&lt;figure id="attachment_249" class="wp-caption aligncenter">&lt;/p>
&lt;p>&lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/easily-add-publications-to-your-orcid-profile/" target="_blank" rel="attachment wp-att-249">&lt;img class="size-medium wp-image-249 " src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/orcid_logged_in-300x231.png" alt="orcid_logged_in" width="300" height="231" srcset="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/orcid_logged_in-300x231.png 300w, https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/orcid_logged_in-624x481.png 624w, https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/orcid_logged_in.png 915w" sizes="(max-width: 300px) 85vw, 300px" />&lt;/a>&lt;figcaption class="wp-caption-text">click on thumbnail to see larger image&lt;/figcaption>&lt;/figure>&lt;/p>
&lt;p>&lt;span >Once you are logged in, you can enter search terms that are likely to return records of your publications:&lt;/span>&lt;figure id="attachment_250" class="wp-caption aligncenter">&lt;/p>
&lt;p>&lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/easily-add-publications-to-your-orcid-profile/" target="_blank" rel="attachment wp-att-250">&lt;img class="size-medium wp-image-250 " src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/crmds_search_terms-300x231.png" alt="crmds_search_terms" width="300" height="231" srcset="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/crmds_search_terms-300x231.png 300w, https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/crmds_search_terms-624x481.png 624w, https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/crmds_search_terms.png 915w" sizes="(max-width: 300px) 85vw, 300px" />&lt;/a>&lt;figcaption class="wp-caption-text">click on thumbnail to see larger image&lt;/figcaption>&lt;/figure>&lt;/p>
&lt;p>&lt;span >Each search result will show an icon telling you whether that particular item is visible in your ORCID profile. If the item is not in your ORCID profile, you see an icon like this:&lt;/span>&lt;/p>
&lt;p >
&lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/easily-add-publications-to-your-orcid-profile/" rel="attachment wp-att-251">&lt;img class="size-full wp-image-251 aligncenter" src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/add_to_orcid_button.png" alt="add_to_orcid_button" width="113" height="30" />&lt;/a>
&lt;/p>
&lt;p>&lt;span >And if the item is already in your ORCID profile, you will see an icon like this:&lt;/span>&lt;/p>
&lt;p >
&lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/easily-add-publications-to-your-orcid-profile/" rel="attachment wp-att-252">&lt;img class="size-full wp-image-252 aligncenter" src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/in_your_profile.png" alt="in_your_profile" width="133" height="27" />&lt;/a>&lt;span >In the following search results you can see that 1 item is already in Josiah Carberry’s profile, and 2 items are not:&lt;/span>
&lt;/p>&lt;figure id="attachment_254" class="wp-caption aligncenter">
&lt;p>&lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/easily-add-publications-to-your-orcid-profile/" target="_blank" rel="attachment wp-att-254">&lt;img class=" wp-image-254 " src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/crmds_search_results.png" alt="crmds_search_results" width="329" height="254" srcset="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/crmds_search_results.png 915w, https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/crmds_search_results-300x231.png 300w, https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/crmds_search_results-624x481.png 624w" sizes="(max-width: 329px) 85vw, 329px" />&lt;/a>&lt;figcaption class="wp-caption-text">click on thumbnail to see larger image&lt;/figcaption>&lt;/figure>&lt;/p>
&lt;p>&lt;span >Clicking on the “Add to Profile” button will confirm that you want to add the specified publication to your ORCID profile:&lt;/span>&lt;figure id="attachment_255" class="wp-caption aligncenter">&lt;/p>
&lt;p>&lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/easily-add-publications-to-your-orcid-profile/" rel="attachment wp-att-255">&lt;img class=" wp-image-255 " src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/crmds_add_work.png" alt="crmds_add_work" width="329" height="254" srcset="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/crmds_add_work.png 915w, https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/crmds_add_work-300x231.png 300w, https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/crmds_add_work-624x481.png 624w" sizes="(max-width: 329px) 85vw, 329px" />&lt;/a>&lt;figcaption class="wp-caption-text">click on thumbnail to see larger image&lt;/figcaption>&lt;/figure>&lt;/p>
&lt;p >
&lt;span >After clicking on &amp;#8220;Yes&amp;#8221; to add the publication to your profile, the search results will refresh to reflect that the item has been added.&lt;/span>
&lt;/p>&lt;figure id="attachment_257" class="wp-caption aligncenter">
&lt;p>&lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/easily-add-publications-to-your-orcid-profile/" target="_blank" rel="attachment wp-att-257">&lt;img class=" wp-image-257 " src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/crmds_work_added.png" alt="crmds_work_added" width="329" height="254" srcset="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/crmds_work_added.png 915w, https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/crmds_work_added-300x231.png 300w, https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/crmds_work_added-624x481.png 624w" sizes="(max-width: 329px) 85vw, 329px" />&lt;/a>&lt;figcaption class="wp-caption-text">click on thumbnail to see larger image&lt;/figcaption>&lt;/figure>&lt;/p>
&lt;p >
&lt;span >You can then just continue searching for and adding any publications that are not in your ORCID profile.&lt;/span>
&lt;/p>
&lt;p >
&lt;span >Note that, occasionally, you may see an orange icon that says that an item is &amp;#8220;Not Visible&amp;#8221;&lt;/span>
&lt;/p>&lt;figure id="attachment_258" class="wp-caption aligncenter">
&lt;p>&lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/easily-add-publications-to-your-orcid-profile/" target="_blank" rel="attachment wp-att-258">&lt;img class="wp-image-258 " src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/not_visible.png" alt="not_visible" width="329" height="254" srcset="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/not_visible.png 915w, https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/not_visible-300x231.png 300w, https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/not_visible-624x481.png 624w" sizes="(max-width: 329px) 85vw, 329px" />&lt;/a>&lt;figcaption class="wp-caption-text">click on thumbnail to see larger image&lt;/figcaption>&lt;/figure>&lt;/p>
&lt;p >
&lt;span >This only occurs when you have previously added an item to your profile using CRMDS and then either:&lt;/span>
&lt;/p>
&lt;ol>
&lt;li>&lt;span >Set the ORCID privacy for that particular work item to “Private” in your ORCID profile.&lt;/span>&lt;/li>
&lt;li>&lt;span >Deleted the work from your ORCID profile.&lt;/span>&lt;/li>
&lt;/ol>
&lt;p>&lt;span >Unfortunately, CRMDS has no way to determine which of these two events occurred  However, If you click on the “Not Visible” icon, you will be prompted with two ways to resolve this issue. Either you can:&lt;/span>&lt;/p>
&lt;ol>
&lt;li>&lt;span >Reset the privacy settings on the specified work to “Public” or “Limited”&lt;/span>&lt;/li>
&lt;li>&lt;span >Confirm to CRMDS that you have deleted the item from your profile.&lt;/span>&lt;figure id="attachment_259" class="wp-caption aligncenter">&lt;/li>
&lt;/ol>
&lt;p>&lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/easily-add-publications-to-your-orcid-profile/" target="_blank" rel="attachment wp-att-259">&lt;img class=" wp-image-259 " src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/not_visible_prompt.png" alt="not_visible_prompt" width="329" height="254" srcset="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/not_visible_prompt.png 915w, https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/not_visible_prompt-300x231.png 300w, https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/not_visible_prompt-624x481.png 624w" sizes="(max-width: 329px) 85vw, 329px" />&lt;/a>&lt;figcaption class="wp-caption-text">click on thumbnail to see larger image&lt;/figcaption>&lt;/figure>&lt;/p>
&lt;p >
&lt;span >If the issue was your privacy settings, then once you have changed the privacy settings to public/limited you can simply click on the &amp;#8220;Refresh&amp;#8221; button and CRMDS will reflect the correct status of the work.&lt;/span>
&lt;/p>
&lt;p >
&lt;span >The best way to avoid this kind of confusion is to go to your ORCID settings and set the default privacy level for &amp;#8220;works&amp;#8221; to either &amp;#8220;limited&amp;#8221; or &amp;#8220;public.&amp;#8221;&lt;/span>
&lt;/p>
&lt;p >
&lt;span >Crossref Metadata Search is still a &amp;#8220;&lt;a title="Crossref Labs" href="https://www-crossref-org.pluma.sjfc.edu/labs/" target="_blank">Crossref Labs&lt;/a>&amp;#8221; project and, as such, we are very interested to hear feedback on this new ORCID functionality for CRMDS. Please send comments, etc. to:&lt;/span>
&lt;/p>
&lt;p >
&lt;span >&lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/easily-add-publications-to-your-orcid-profile/" rel="attachment wp-att-261">&lt;img class="alignnone size-full wp-image-261" src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/uploads/2013/01/labs_email.png" alt="labs_email" width="233" height="42" />&lt;/a>&lt;/span>
&lt;/p></description></item><item><title>Crossref Metadata Search++</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/crossref-metadata-search-plus-plus/</link><pubDate>Thu, 11 Oct 2012 00:00:00 +0000</pubDate><author>Geoffrey Bilder</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/crossref-metadata-search-plus-plus/</guid><description>&lt;p>We have just released a bunch of new functionality for &lt;a href="https://web.archive.org/web/20131229210637/http://search.crossref.org.pluma.sjfc.edu//" target="_blank">Crossref Metadata Search&lt;/a>. The tool now supports the following features:&lt;/p>
&lt;ul class="disc" >
&lt;li>
A completely new UI
&lt;/li>
&lt;li>
&lt;a href="http://en.wikipedia.org/wiki/Faceted_search" rel="external" target="_blank" >Faceted&lt;/a>&lt;span class="Apple-converted-space">&amp;nbsp;&lt;/span>searches
&lt;/li>
&lt;li>
Copying of search results as formatted citations using&lt;span class="Apple-converted-space">&amp;nbsp;&lt;/span>&lt;a href="http://en.wikipedia.org/wiki/Citation_Style_Language" rel="external" target="_blank" >CSL&lt;/a>
&lt;/li>
&lt;li>
&lt;a href="http://en.wikipedia.org/wiki/COinS" rel="external" target="_blank" >COinS&lt;/a>, so that you can easily import results into Zotero and other document management tools
&lt;/li>
&lt;li>
&lt;a href="http://web.archive.org/web/20121014215757/http://search.labs.crossref.org.pluma.sjfc.edu/help/api" rel="external" target="_blank" >An API&lt;/a>, so that you can integrate Crossref Metadata Search into your own applications, plugins, etc.
&lt;/li>
&lt;li>
Basic&lt;span class="Apple-converted-space">&amp;nbsp;&lt;/span>&lt;a href="http://en.wikipedia.org/wiki/OpenSearch" rel="external" target="_blank" >OpenSearch&lt;/a>&lt;span class="Apple-converted-space">&amp;nbsp;&lt;/span>support- so that you can integrate Crossref Metadata Search into your browser’s search bar.
&lt;/li>
&lt;li>
Searching for a particular Crossref DOI
&lt;/li>
&lt;li>
Searching for a particular Crossref&lt;span class="Apple-converted-space">&amp;nbsp;&lt;/span>&lt;a href="http://shortdoi.org/" rel="external" target="_blank" >ShortDOI&lt;/a>
&lt;/li>
&lt;li>
Searching for articles in a particular journal via the journal’s ISSN
&lt;/li>
&lt;/ul>
&lt;p>At the moment, Crossref Metadata Search (CRMDS) is a &lt;a href="https://www-crossref-org.pluma.sjfc.edu/labs/" target="_blank">Crossref Labs project&lt;/a> and, as such, should be used with some trepidation. Our goal is to release CRMS as a production service ASAP, but we wanted to get public feedback on the service before making the move to a production system.&lt;/p></description></item><item><title>OpenSearch/SRU Integration Paper</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/opensearch/sru-integration-paper/</link><pubDate>Mon, 19 Jul 2010 00:00:00 +0000</pubDate><author>Tony Hammond</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/opensearch/sru-integration-paper/</guid><description>&lt;p>Since I’ve already blogged about this a number of times before here, I thought I ought to include a link to a fuller writeup in this month’s &lt;a href="http://dlib.org" target="_blank">D-Lib Magazine&lt;/a> of our &lt;a href="https://www-nature-com.pluma.sjfc.edu/opensearch/" target="_blank">nature.com OpenSearch&lt;/a> service which serves as a case study in OpenSearch and SRU integration:&lt;/p>
&lt;p>&lt;a href="http://dlib.org/dlib/july10/hammond/07hammond.html" target="_blank">&lt;img border="0" src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/images/dlib-page.png" height="320" width="450" />&lt;/a>&lt;/p>
&lt;p>&lt;a href="http://dlib.org/dlib/july10/hammond/07hammond.html" target="_blank">doi:10.1045/july2010-hammond&lt;/a>&lt;/p></description></item><item><title>Search: An Evolution</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/search-an-evolution/</link><pubDate>Wed, 28 Apr 2010 00:00:00 +0000</pubDate><author>Tony Hammond</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/search-an-evolution/</guid><description>&lt;p>&lt;a href="https://www-crossref-org.pluma.sjfc.edu/wp/blog/images/search-triple-store.png">&lt;img border=0 alt="doi-what-do-we-got.png" src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/images/search-triple-store.png" width="416" height="325" />&lt;/a>&lt;/p>
&lt;p>(Click image for full size graphic.)&lt;/p>
&lt;p>I thought I could take this opportunity to demonstrate one evolution path from traditional record-based search to a more contemporary triple-based search. The aim is to show that these two modes of search do not have to be alternative approaches but can co-exist within a single workflow.&lt;/p>
&lt;p>Let me first mention a couple of terms I’m using here: ‘graphs’ and ‘properties’. I’m using ‘property’ loosely to refer to the individual RDF statement (or triple) containing a property, i.e. a triple is a ‘(subject, property, value)’ assertion. And a ‘graph’ is just a collection of ‘properties’ (or, more properly, triples). Oh, and I’ll also use the term ‘records’ when considering ‘graphs’ as pre-fabricated objects returned within a result set.&lt;/p>
&lt;p>So, what do we have here? We have on the left a traditional means of disseminating search results which is typically record based. A new set of records may be generated by querying using the API provided, whether proprietary or public such as &lt;a href="https://lucene.apache.org/" target="_blank">Lucene&lt;/a> or &lt;a href="http://www.loc.gov/standards/sru/" target="_blank">SRU/CQL&lt;/a>. We can thus consider this search service as a ‘record store’ – even though records tend to generated anew rather than retrieved. The individual records in the result set are collections or groupings of ‘properties’ about the subjects of the query. Note that this is somewhat similar to the way music is packaged for physical distribution with many tracks (‘properties’) combined onto a single album (‘record’ or ‘graph’) which contains a thematic coherence – either same artist or compilation around a given topic.&lt;/p>
&lt;p>Digital music distribution, on the other hand, allows for albums to be atomized so that individual tracks may be cherry-picked at will. This is not dissimilar from what happens in a ‘triple store’ where the basic properties (‘tracks’) that in a regular search engine were together combined in a ‘record’ (‘album’) to present a search result can now be plucked apart and recombined into newer bespoke ensembles. Note that this querying and recombination can be applied across the full triple store or even across this triple store and remote triple stores since the same data model is applied. Certainly, at the data model level federated searching thus becomes a non-issue.&lt;/p>
&lt;p>Suppose now that our search server (or record store) is an &lt;a href="http://www.opensearch.org/" target="_blank">OpenSearch&lt;/a>-type service, i.e. the result sets are distributed as some list-based format, typically RSS, and that the list-based format either provides an RDF graph or can be transformed to such a graph, we could then use that as a basis for feeding an RDF triple store.&lt;/p>
&lt;p>So, now then at right we have a triple store which is a large database of triples (or properties) compiled from all the records in the record store. And since this is a triple store we can query it using &lt;a href="http://www.w3.org/TR/rdf-sparql-query/" target="_blank">SPARQL&lt;/a>. For example, this trival SPARQL query:&lt;/p>
&lt;pre>&lt;tt>
PREFIX dc: &amp;lt;http://purl.org/dc/elements/1.1/&amp;gt;
PREFIX prism: &amp;lt;http://prismstandard.org/namespaces/basic/2.0/&amp;gt;
SELECT ?doi ?title
WHERE {
?s prism:doi ?doi .
?s dc:title ?title .
FILTER regex(?title, "boson", "i" )
}
LIMIT 5
&lt;/tt>&lt;/pre>
&lt;p>returns the first five articles (referenced by DOI) with title containing the word ‘boson’:&lt;/p>
&lt;pre>&lt;tt>
--------------------------------------------------------------------------------------------------
| doi | title |
==================================================================================================
| "10.1038/nature05513" | "Comparison of the Hanbury Brown–Twiss effect for bosons and fermions" |
| "10.1038/221999a0" | "Physics: The Intermediate Boson" |
| "10.1038/313506b0" | "The nuts and bolts of bosons" |
| "10.1038/301287a0" | "The search for bosons: A golden year for the weak force" |
| "10.1038/424003a" | "Below-par performance hampers Fermilab quest for Higgs boson" |
--------------------------------------------------------------------------------------------------
&lt;/tt>&lt;/pre>
&lt;p>Now let’s contrast this with a conventional record-based search, such as shown at left, to find the first five articles (referenced by DOI) with title containing the word ‘boson’ would use a query (here SRU/CQL, and CQL is bolded) such as:&lt;/p>
&lt;pre>&lt;tt>
?query=&lt;b>dc.title="boson"&lt;/b>&amp;maximumRecords=5&amp;httpAccept=application/rss+xml
&lt;/tt>&lt;/pre>
&lt;p>and would receive a set of result records (here RSS) like so:&lt;/p>
&lt;pre>&lt;tt>
...
&amp;lt;item rdf:about="http://dx.doi.org.pluma.sjfc.edu/10.1038/nature05513"&amp;gt;
&amp;lt;title&amp;gt;Comparison of the Hanbury Brown–Twiss effect for bosons and fermions&amp;lt;/title&amp;gt;
&amp;lt;link&amp;gt;http://dx.doi.org.pluma.sjfc.edu/10.1038/nature05513&amp;lt;/link&amp;gt;
&amp;lt;dc:identifier&amp;gt;doi:10.1038/nature05513&amp;lt;/dc:identifier&amp;gt;
&amp;lt;dc:title&amp;gt;Comparison of the Hanbury Brown–Twiss effect for bosons and fermions&amp;lt;/dc:title&amp;gt;
...
&amp;lt;/item&amp;gt;
&amp;lt;item rdf:about="http://dx.doi.org.pluma.sjfc.edu/10.1038/221999a0"&amp;gt;
&amp;lt;title&amp;gt;Physics: The Intermediate Boson&amp;lt;/title&amp;gt;
&amp;lt;link&amp;gt;http://dx.doi.org.pluma.sjfc.edu/10.1038/221999a0&amp;lt;/link&amp;gt;
&amp;lt;dc:identifier&amp;gt;doi:10.1038/221999a0&amp;lt;/dc:identifier&amp;gt;
&amp;lt;dc:title&amp;gt;Physics: The Intermediate Boson&amp;lt;/dc:title&amp;gt;
...
&amp;lt;/item&amp;gt;
...
&lt;/tt>&lt;/pre>
&lt;p>Note also that there is an interesting halfway house as shown in the diagram, whereby a set of result records presenting a single RDF graph can be queried as its own (very) restricted triple store.&lt;/p>
&lt;p>In general, because a triple store is so primitive and it can be queried alongside other triple stores the queries that can be put together can be highly complex and customized with arbitrary data. The result from such a query differs from a traditional ‘record’ where a fixed property set is bound together in a presentation. Such a result is user-determined as opposed to the server-determined nature of traditional result ‘records’.&lt;/p>
&lt;p>I hope that this post has been able to show in some degree that although there are some obvious differences there is nevertheless a synergy between these two modes of searching: prêt-à-porter and tailored.&lt;/p></description></item><item><title>got SEARCH if you want it!</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/got-search-if-you-want-it/</link><pubDate>Tue, 24 Nov 2009 00:00:00 +0000</pubDate><author>Tony Hammond</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/got-search-if-you-want-it/</guid><description>&lt;p>[See this link if you’re short on time: &lt;a href="http://nurture.nature.com.pluma.sjfc.edu/opensearch/apps/client-facets.html" target="_blank">facets&lt;/a> search client. Only tested on Firefox at this point. &lt;strong>Caveat:&lt;/strong> At time of writing the Crossref Metadata Search was being &lt;em>very&lt;/em> slow but was still functional. Previously it was just slow.]&lt;/p>
&lt;p>Following on from Geoff’s &lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/crossref-labs/">announcement&lt;/a> last month of a prototype Crossref Metadata OpenSearch on &lt;a href="https://www-crossref-org.pluma.sjfc.edu/labs/" target="_blank">labs.crossref.org&lt;/a>, I wanted to show what typical OpenSearch responses might look like in a more mature implementation.&lt;/p>
&lt;p>I have taken the liberty of modelling these on the response formats that we are already providing in our nature.com OpenSearch service which in turn are based on the draft syndication formats that I &lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/opensearch-formats-for-review/">blogged here&lt;/a> earlier.&lt;/p>
&lt;p>I am therefore returning ATOM, JSON, JSONP and RSS responses from these four OpenSearch URL templates:&lt;/p>
&lt;ul>
&lt;li>&lt;a href="http://nurture.nature.com.pluma.sjfc.edu/cgi-bin/opensearch?db=crossref&amp;amp;#038;out=atom&amp;amp;#038;q=%7bsearchTerms%7d" target="_blank">http://nurture.nature.com.pluma.sjfc.edu/cgi-bin/opensearch?db=crossref&amp;#038;out=atom&amp;#038;q={searchTerms}&lt;/a>
&lt;ul>
&lt;li>&lt;a href="http://nurture.nature.com.pluma.sjfc.edu/cgi-bin/opensearch?db=crossref&amp;amp;#038;out=json&amp;amp;#038;q=%7bsearchTerms%7d" target="_blank">http://nurture.nature.com.pluma.sjfc.edu/cgi-bin/opensearch?db=crossref&amp;#038;out=json&amp;#038;q={searchTerms}&lt;/a>
&lt;ul>
&lt;li>&lt;a href="http://nurture.nature.com.pluma.sjfc.edu/cgi-bin/opensearch?db=crossref&amp;amp;#038;out=jsonp&amp;amp;#038;q=%7bsearchTerms%7d" target="_blank">http://nurture.nature.com.pluma.sjfc.edu/cgi-bin/opensearch?db=crossref&amp;#038;out=jsonp&amp;#038;q={searchTerms}&lt;/a>
&lt;ul>
&lt;li>
&lt;p>&lt;a href="http://nurture.nature.com.pluma.sjfc.edu/cgi-bin/opensearch?db=crossref&amp;amp;#038;out=rss&amp;amp;#038;q=%7bsearchTerms%7d" target="_blank">http://nurture.nature.com.pluma.sjfc.edu/cgi-bin/opensearch?db=crossref&amp;#038;out=rss&amp;#038;q={searchTerms}&lt;/a>&lt;/ul>
as this &lt;a href="http://nurture.nature.com.pluma.sjfc.edu/opensearch/xml/opencrossref.xml" target="_blank">OpenSearch description&lt;/a> file details. Note that the URL templates include no indexing or pagination parameters as the Crossref prototype does not currently support these features.&lt;/p>
&lt;p>An example query (‘apple’) returning an ATOM feed from a Crossref Metadata OpenSearch would be the following:&lt;/p>
&lt;ul>
&lt;li>
&lt;p>&lt;a href="http://nurture.nature.com.pluma.sjfc.edu/cgi-bin/opensearch?db=crossref&amp;amp;#038;out=atom&amp;amp;#038;q=apple" target="_blank">http://nurture.nature.com.pluma.sjfc.edu/cgi-bin/opensearch?db=crossref&amp;#038;out=atom&amp;#038;q=apple&lt;/a>&lt;/ul>
And the same query returning a JSON version of that ATOM feed would look as follows:&lt;/p>
&lt;ul>
&lt;li>
&lt;p>&lt;a href="http://nurture.nature.com.pluma.sjfc.edu/cgi-bin/opensearch?db=crossref&amp;amp;#038;out=json&amp;amp;#038;q=apple" target="_blank">http://nurture.nature.com.pluma.sjfc.edu/cgi-bin/opensearch?db=crossref&amp;#038;out=json&amp;#038;q=apple&lt;/a>&lt;/ul>
By the way, this is just for demonstration purposes and there are still issues to be resolved including character encoding.&lt;/p>
&lt;p>This interface uses the existing Crossref OpenSearch response format and parses the &lt;a href="https://web.archive.org/web/20090927174724/http://ocoins.info/" target="_blank">COinS&lt;/a> objects embedded in that response to provide a more standard OpenSearch syndication result set format. The prototype implemenatation also has some bugs which I needed to work around. (I will forward on details of these.) And there is also a more fundamental issue of response time from the experimental search server.&lt;/p>
&lt;p>But still this should give some idea of what a Crossref Metadata OpenSearch service could look like.&lt;/p>
&lt;p>To show this all in action I’ve worked up one of my &lt;a href="http://nurture.nature.com.pluma.sjfc.edu/opensearch/apps/client-facets.html" target="_blank">demo OpenSearch clients&lt;/a> for &lt;a href="http://www.nature.com.pluma.sjfc.edu/opensearch/" target="_blank">nature.com OpenSearch&lt;/a> which displays a facetted search response for a Crossref search. For good measure this includes also an OpenSearch interface for PubMed and the search client allows for simple selection between three journals databases: nature.com, Crossref and PubMed.&lt;/p>
&lt;p>Of course, with a reasonably uniform set of search result formats such as presented here it then becomes a simple exercise to reuse these search responses in additional search clients.&lt;/p>
&lt;p>As can be anticipated it would be very straightforward to carry this over into a single metasearch service which could run across these multiple databases.&lt;/p>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul></description></item><item><title>A Cheatsheet for nature.com OpenSearch</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/a-cheatsheet-for-nature.com-opensearch/</link><pubDate>Thu, 22 Oct 2009 00:00:00 +0000</pubDate><author>Tony Hammond</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/a-cheatsheet-for-nature.com-opensearch/</guid><description>&lt;img alt="opensearch-cheatsheet-fragment.png" src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/images/opensearch-cheatsheet-fragment.png" width="328" height="267" />
&lt;p>Following on from my &lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/nature.com-opensearch-a-structured-search-service/">recent post&lt;/a> about our shiny new &lt;a href="http://www.nature.com.pluma.sjfc.edu/opensearch" target="_blank">nature.com OpenSearch&lt;/a> service we just put up a cheatsheet for users. I’m posting about this here as this may also be of interest especially to those exploring how SRU and OpenSearch intersect.&lt;/p>
&lt;p>The cheatsheet can be downloaded from our nature.com OpenSearch &lt;a href="http://nurture.nature.com.pluma.sjfc.edu/opensearch" target="_blank">test page&lt;/a> and is available in two forms:&lt;/p>
&lt;ul>
&lt;li>&lt;a href="http://nurture.nature.com.pluma.sjfc.edu/opensearch/docs/opensearch-cheatsheet.pdf" target="_blank">Cheatsheet (PDF, 65K)&lt;/a>
&lt;ul>
&lt;li>&lt;a href="http://nurture.nature.com.pluma.sjfc.edu/opensearch/docs/opensearch-cheatsheet.png" target="_blank">Cheatsheet (PNG, 141K)&lt;/a>&lt;/ul>
Naurally, all comments welcome.&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul></description></item><item><title>nature.com OpenSearch: A Structured Search Service</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/nature.com-opensearch-a-structured-search-service/</link><pubDate>Mon, 05 Oct 2009 00:00:00 +0000</pubDate><author>Tony Hammond</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/nature.com-opensearch-a-structured-search-service/</guid><description>&lt;map name="GraffleExport">
&lt;area shape=rect coords="266,26,519,220" href="https://web.archive.org/web/20070815000000*/http://blogs.nature.com.pluma.sjfc.edu/wp/nascent/2009/10/naturecom_opensearch.html"> &lt;area shape=rect coords="230,220,486,414" href="https://web.archive.org/web/20070815000000*/http://blogs.nature.com.pluma.sjfc.edu/wp/nascent/2009/10/desktop_widgets_naturecom_sear.html"> &lt;area shape=rect coords="231,220,487,414" href="https://web.archive.org/web/20070815000000*/http://blogs.nature.com.pluma.sjfc.edu/wp/nascent/2009/10/desktop_widgets_naturecom_sear.html"> &lt;area shape=rect coords="2,123,253,317" href="https://web.archive.org/web/20070815000000*/http://blogs.nature.com.pluma.sjfc.edu/wp/nascent/2009/10/web_clients_for_naturecom_open.html">
&lt;/map>
&lt;img border="0" alt="opensearch-triptych.jpg" src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/images/opensearch-triptych.jpg" width="522" height="438" usemap="#GraffleExport" />
&lt;p>(Click panels in figure to read related posts.)&lt;/p>
&lt;p>Following up on my earlier posts here about the structured search technologies &lt;a href="http://www.opensearch.org/" target="_blank">OpenSearch&lt;/a> and &lt;a href="http://www.loc.gov/standards/sru/" target="_blank">SRU&lt;/a>, I wanted to reference three recent posts on our web publishing blog Nascent which discuss our new &lt;a href="http://www.nature.com.pluma.sjfc.edu/opensearch" target="_blank">&lt;em>nature.com OpenSearch&lt;/em>&lt;/a> service:&lt;/p>
&lt;dl>
&lt;dt>&lt;a href="https://web.archive.org/web/20070815000000*/http://blogs.nature.com.pluma.sjfc.edu/wp/nascent/2009/10/naturecom_opensearch.html" target="_blank">1. Service&lt;/a>&lt;/dt>
&lt;dd>Describes the new &lt;a href="http://www.nature.com.pluma.sjfc.edu/opensearch" target="_blank">&lt;em>nature.com OpenSearch&lt;/em>&lt;/a> service which provides a structured resource discovery facility for content hosted on nature.com.&lt;/dd>
&lt;dt>&lt;a href="https://web.archive.org/web/20070815000000*/http://blogs.nature.com.pluma.sjfc.edu/wp/nascent/2009/10/web_clients_for_naturecom_open.html" target="_blank">2. Clients&lt;/a>&lt;/dt>
&lt;dd>Points to a small gallery of &lt;a href="http://nurture.nature.com.pluma.sjfc.edu/opensearch/apps" target="_blank">demo web clients&lt;/a> for &lt;em>nature.com OpenSearch&lt;/em> which all use the text-based JSON interface.&lt;/dd>
&lt;dt>&lt;a href="https://web.archive.org/web/20070815000000*/http://blogs.nature.com.pluma.sjfc.edu/wp/nascent/2009/10/desktop_widgets_naturecom_sear.html" target="_blank">3. Widgets&lt;/a>&lt;/dt>
&lt;dd>Introduces the new &lt;em>nature.com search&lt;/em> &lt;a href="https://web.archive.org/web/20110309190725/http://www.nature.com.pluma.sjfc.edu/libraries/public_interfaces/widgets.html" target="_blank">desktop widgets&lt;/a> which interface with the &lt;em>nature.com OpenSearch&lt;/em> service via an RSS feed. (See also the &lt;a href="http://www.youtube.com/watch?v=sqf_ew4o3U8" target="_blank">screencast&lt;/a> posted to YouTube.)&lt;/dd>
&lt;/dl>
&lt;p>We hope that this new search service will prove to be useful and may also provide a model for other implementations.&lt;/p></description></item><item><title>OpenSearch Formats for Review</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/opensearch-formats-for-review/</link><pubDate>Thu, 23 Jul 2009 00:00:00 +0000</pubDate><author>Tony Hammond</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/opensearch-formats-for-review/</guid><description>&lt;p>In an &lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/structured-search-using-prism-elements/">earlier post&lt;/a> I talked about using the PAM (PRISM Aggregator Message) schema for an SRU result set. I have also noted in &lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/search-web-service">another post&lt;/a> that a Search Web Service could support both &lt;a href="http://www.loc.gov/standards/sru/" target="_blank">SRU&lt;/a> and &lt;a href="http://opensearch.org/" target="_blank">OpenSearch&lt;/a> interfaces. This does then beg the question of what a corresponding OpenSearch result set might look like for such a record.&lt;/p>
&lt;p>Based on the &lt;a href="http://www.opensearch.org/Specifications/OpenSearch/1.1" target="_blank">OpenSearch spec&lt;/a> and also on a new &lt;a href="http://www.oasis-open.org/committees/download.php/33410/atom-extension-for-sru.doc" target="_blank">Atom extension for SRU&lt;/a>, I have contrived to show how a PAM record might be returned in a coomon OpenSearch format. Below I offer some mocked-up examples for each of the following formats for review purposes:&lt;/p>
&lt;ul>
&lt;li>RSS 1.0
&lt;ul>
&lt;li>ATOM
&lt;ul>
&lt;li>
&lt;p>JSON &lt;/ul>
Just click the relevant figure for a text rendering of each result format for the following phrase search:&lt;/p>
&lt;blockquote>
&lt;p>cql.keywords adj “solar eclipse”&lt;/p>
&lt;/blockquote>
&lt;p>In this example we imagine that two records have been requested. (The example formats also include navigational links as per the OpenSearch spec examples.)&lt;/p>
&lt;p>Note that the JSON example closely follows the ATOM schema with a couple of main deviations:&lt;/p>
&lt;ul>
&lt;li>Repeated elements are gathered together in an array (e.g. “entry”, “dc:creator”)
&lt;ul>
&lt;li>
&lt;p>Attributes are broken out alongside their parent elements (e.g. “rel”, “href”)&lt;/ul>
It would be interesting to hear what readers think of these examples - especially the JSON format.&lt;/p>
&lt;table cellpadding="10" border="0">
&lt;tr>
&lt;td>
&lt;a href="http://nurture.nature.com.pluma.sjfc.edu/opensearch/demo/solar2-rss.txt">&lt;img alt="solar2-rss.jpg" border="0" width="159" height="309" src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/images/solar2-rss.jpg" />&lt;/a>
&lt;/td>
&lt;pre>&lt;code>&amp;lt;td&amp;gt;
&amp;lt;a href=&amp;quot;http://nurture.nature.com.pluma.sjfc.edu/opensearch/demo/solar2-atom.txt&amp;quot;&amp;gt;&amp;lt;img alt=&amp;quot;solar2-atom.jpg&amp;quot; border=&amp;quot;0&amp;quot; width=&amp;quot;159&amp;quot; height=&amp;quot;309&amp;quot; src=&amp;quot;/wp/blog/images/solar2-atom.jpg&amp;quot; /&amp;gt;&amp;lt;/a&amp;gt;
&amp;lt;/td&amp;gt;
&amp;lt;td&amp;gt;
&amp;lt;a href=&amp;quot;http://nurture.nature.com.pluma.sjfc.edu/opensearch/demo/solar2-json.txt&amp;quot;&amp;gt;&amp;lt;img alt=&amp;quot;solar2-json.jpg&amp;quot; border=&amp;quot;0&amp;quot; width=&amp;quot;159&amp;quot; height=&amp;quot;309&amp;quot; src=&amp;quot;/wp/blog/images/solar2-json.jpg&amp;quot; /&amp;gt;&amp;lt;/a&amp;gt;
&amp;lt;/td&amp;gt;
&lt;/code>&lt;/pre>
&lt;/tr>
&lt;tr>
&lt;th>
RSS 1.0
&lt;/th>
&lt;pre>&lt;code>&amp;lt;th&amp;gt;
ATOM
&amp;lt;/th&amp;gt;
&amp;lt;th&amp;gt;
JSON
&amp;lt;/th&amp;gt;
&lt;/code>&lt;/pre>
&lt;/tr>
&lt;/table>
&lt;p>(Click image to get text format.)&lt;/p>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul></description></item><item><title>OASIS Drafts of SRU 2.0 and CQL 2.0</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/oasis-drafts-of-sru-2.0-and-cql-2.0/</link><pubDate>Wed, 22 Jul 2009 00:00:00 +0000</pubDate><author>Tony Hammond</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/oasis-drafts-of-sru-2.0-and-cql-2.0/</guid><description>&lt;p>As posted &lt;a href="http://listserv.loc.gov/cgi-bin/wa?A2=ind0907&amp;amp;#038;L=zng&amp;amp;#038;T=0&amp;amp;#038;P=52" target="_blank">here&lt;/a> on the &lt;a href="https://web.archive.org/web/20130303230855/http://sun8.loc.gov/listarch/zng.html" target="_blank">SRU Implementors&lt;/a> list, the &lt;a href="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=search-ws" target="_blank">OASIS Search Web Services Technical Committee&lt;/a> has announced the release of drafts of SRU and CQL version 2.0:&lt;/p>
&lt;ul>
&lt;li>&lt;a href="http://www.oasis-open.org/committees/download.php/33498/sru-2-0-draft.doc" target="_blank">sru-2-0-draft.doc&lt;/a>
&lt;ul>
&lt;li>&lt;a href="http://www.oasis-open.org/committees/download.php/33497/cql-2-0-draft.doc" target="_blank">cql-2-0-draft.doc&lt;/a> &lt;/ul>
The Committee is soliciting feedback on these two documents. Comments should be &lt;a href="https://web.archive.org/web/20130303230855/http://sun8.loc.gov/listarch/zng.html" target="_blank">posted to the SRU list&lt;/a> by August 13.&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul></description></item><item><title>Aligning OpenSearch and SRU</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/aligning-opensearch-and-sru/</link><pubDate>Fri, 05 Jun 2009 00:00:00 +0000</pubDate><author>Tony Hammond</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/aligning-opensearch-and-sru/</guid><description>&lt;p>[&lt;strong>Update - 2009.06.07:&lt;/strong> As pointed out by Todd Carpenter of NISO (see comments below) the phrase “&lt;em>SRU by contrast is an initiative to update Z39.50 for the Web&lt;/em>” is inaccurate. I should have said “&lt;em>By contrast SRU is an initiative recognized by ZING (Z39.50 International Next Generation) to bring Z39.50 functionality into the mainstream Web&lt;/em>“.]&lt;/p>
&lt;p>[&lt;strong>Update - 2009.06.08:&lt;/strong> Bizarrely I find in mentioning query languages below that I omitted to mention SQL. I don’t know what that means. Probably just that there’s no Web-based API. And that again it’s tied to a particular technology - RDBMS.]&lt;/p>
&lt;p>&lt;a href="https://www-crossref-org.pluma.sjfc.edu/wp/blog/images/queryType.png">&lt;img alt="queryType.png" src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/images/queryType.png" width="379" height="261" border="0" />&lt;/a>&lt;/p>
&lt;p>(Click image to enlarge.)&lt;/p>
&lt;p>There are two well-known public search APIs for generic Web-based search: &lt;a href="http://www.opensearch.org/" target="_blank">OpenSearch&lt;/a> and &lt;a href="http://www.loc.gov/standards/sru/" target="_blank">SRU&lt;/a>. (Note that the key term here is “generic”, so neither &lt;a href="http://lucene.apache.org/solr/" target="_blank">Solr&lt;/a>/&lt;a href="http://lucene.apache.org/" target="_blank">Lucene&lt;/a> nor &lt;a href="http://www.w3.org/XML/Query/" target="_blank">XQuery&lt;/a> really qualify for that slot. Also, I am concentrating here on “classic” query languages rather than on semantic query languages such as &lt;a href="http://www.w3.org/2009/sparql/wiki/Main_Page" target="_blank">SPARQL&lt;/a>.)&lt;/p>
&lt;p>OpenSearch was created by Amazon’s &lt;a href="https://web.archive.org/web/20090610223844/http://a9.com/" target="_blank">A9.com&lt;/a> and is a cheap and cheerful means to interface to a search service by declaring a template URL and returning a structured XML format. It therefore allows for structured result sets while placing no constraints on the query string. As outlined in my earlier post &lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/search-web-service">Search Web Service&lt;/a>, there is support for search operation control parameters (pagination, encoding, etc.), but no inroads are made into the query string itself which is regarded as opaque.&lt;/p>
&lt;p>SRU by contrast is an initiative to update &lt;a href="http://www.loc.gov/z3950/agency/" target="_blank">Z39.50&lt;/a> for the Web and is firmly focussed on structured queries and responses. Specifically a query can be expressed in the high-level query language &lt;a href="http://www.loc.gov/standards/sru/specs/cql.html" target="_blank">CQL&lt;/a> which is independent of any underlying implementation. Result records are returned using any declared W3C XML Schema format and are transported within a defined XML wrapper format for SRU. (Note that the &lt;a href="https://www.oasis-open.org/committees/documents.php?wg_abbrev=search-ws" target="_blank">SRU 2.0 draft&lt;/a> provides support for arbitrary result formats based on media type.)&lt;/p>
&lt;p>One can summarize the respective OpenSearch and SRU functionalities as in this table:&lt;/p>
&lt;table border="1" width="50%">
&lt;tr>
&lt;th width="33%" align="left">
Structure
&lt;/th>
&lt;pre>&lt;code>&amp;lt;th width=&amp;quot;33%&amp;quot; align=&amp;quot;center&amp;quot;&amp;gt;
OpenSearch
&amp;lt;/th&amp;gt;
&amp;lt;th width=&amp;quot;33%&amp;quot; align=&amp;quot;center&amp;quot;&amp;gt;
SRU
&amp;lt;/th&amp;gt;
&lt;/code>&lt;/pre>
&lt;/tr>
&lt;tr>
&lt;td>
query
&lt;/td>
&lt;pre>&lt;code>&amp;lt;td align=&amp;quot;center&amp;quot;&amp;gt;
no
&amp;lt;/td&amp;gt;
&amp;lt;td align=&amp;quot;center&amp;quot;&amp;gt;
yes
&amp;lt;/td&amp;gt;
&lt;/code>&lt;/pre>
&lt;/tr>
&lt;tr>
&lt;td>
results
&lt;/td>
&lt;pre>&lt;code>&amp;lt;td align=&amp;quot;center&amp;quot;&amp;gt;
yes
&amp;lt;/td&amp;gt;
&amp;lt;td align=&amp;quot;center&amp;quot;&amp;gt;
yes
&amp;lt;/td&amp;gt;
&lt;/code>&lt;/pre>
&lt;/tr>
&lt;tr>
&lt;td>
control
&lt;/td>
&lt;pre>&lt;code>&amp;lt;td align=&amp;quot;center&amp;quot;&amp;gt;
yes
&amp;lt;/td&amp;gt;
&amp;lt;td align=&amp;quot;center&amp;quot;&amp;gt;
yes
&amp;lt;/td&amp;gt;
&lt;/code>&lt;/pre>
&lt;/tr>
&lt;tr>
&lt;td>
diagnostics
&lt;/td>
&lt;pre>&lt;code>&amp;lt;td align=&amp;quot;center&amp;quot;&amp;gt;
no
&amp;lt;/td&amp;gt;
&amp;lt;td align=&amp;quot;center&amp;quot;&amp;gt;
yes
&amp;lt;/td&amp;gt;
&lt;/code>&lt;/pre>
&lt;/tr>
&lt;/table>
&lt;p>What I wanted to discuss here was the OpenSearch and SRU interfaces to a &lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/search-web-service">Search Web Service&lt;/a> such as outlined in my previous post. The &lt;a href="https://www-crossref-org.pluma.sjfc.edu/wp/blog/images/queryType.png">diagram&lt;/a> at top of this post shows query forms for OpenSearch and SRU and associated result types. The Search Web Service is taken to be exposing an SRU interface. It might be simplest to walk through each of the cases.&lt;/p>
&lt;p>(Continues below.)&lt;/p>
&lt;p>&lt;em>Case 1: OpenSearch (Native Client)&lt;/em>&lt;/p>
&lt;p>As noted, OpenSearch uses a URL template (declared in an OpenSearch description document) where recognized parameters are mapped to implementation-specific parameters. The bolded parameter “&lt;strong>query&lt;/strong>” in the figure indicates an OpenSearch parameter “&lt;strong>searchTerms&lt;/strong>” which has been mapped to the Search Web Service parameter “&lt;strong>query&lt;/strong>“,&lt;/p>
&lt;p>As also noted, SRU 2.0 offers support for alternate result formats (other than SRU XML) by allowing a media type (aka mime type) to be passed in an “http:accept” parameter. There is, however, no OpenSearch parameter corresponding to a format selector, so this must be hard coded directly into the URL template with a value of “application/rss+xml” - the standard media type for an RSS feed which is the common result format for OpenSearch.&lt;/p>
&lt;p>(In the diagram I have noted in parentheses that RSS in its RSS 1.0 form is RDF. And that format is a strong candidate for semantic interoperability. An alternate format would be Atom, which could be similarly selected with a value of “application/atom+xml”, but it is difficult to see at this time what advantage Atom confers. It does not conform to the RDF data model but may find better support in code libraries and applications.)&lt;/p>
&lt;p>The third parameter shown for Case 1, is “queryType” which is another new SRU 2.0 parameter. I had noted earlier that an OpenSearch query string could be passed directly through to the Search Web Service and its associated CQL parser. It tuns out that this needs to be analyzed further. (And many thanks to Jonathan Rochkind for useful discussions on this.)&lt;/p>
&lt;p>I had naively assumed that an OpenSearch query string would either be packed as a CQL string or would be a simple text string which could be interpreted as CQL. The latter interpretation (text string) turns out to be true only for a single bare word or for a quoted string - both of which are recognized CQL query strings (i.e. a single search term which has a default index and relationship to that index). It fails, however, for the more general case of unquoted strings. See table below for these cases.&lt;/p>
&lt;table border="1" width="50%">
&lt;tr>
&lt;th width="50%">
Query type
&lt;/th>
&lt;pre>&lt;code>&amp;lt;th width=&amp;quot;50%&amp;quot;&amp;gt;
Query string
&amp;lt;/th&amp;gt;
&lt;/code>&lt;/pre>
&lt;/tr>
&lt;tr>
&lt;td>
A. bare word
&lt;/td>
&lt;pre>&lt;code>&amp;lt;td align=&amp;quot;left&amp;quot;&amp;gt;
this
&amp;lt;/td&amp;gt;
&lt;/code>&lt;/pre>
&lt;/tr>
&lt;tr>
&lt;td>
B. quoted string
&lt;/td>
&lt;pre>&lt;code>&amp;lt;td align=&amp;quot;left&amp;quot;&amp;gt;
&amp;amp;#8220;this is a query&amp;amp;#8221;
&amp;lt;/td&amp;gt;
&lt;/code>&lt;/pre>
&lt;/tr>
&lt;tr>
&lt;td>
C. unquoted string
&lt;/td>
&lt;pre>&lt;code>&amp;lt;td align=&amp;quot;left&amp;quot;&amp;gt;
this is a query
&amp;lt;/td&amp;gt;
&lt;/code>&lt;/pre>
&lt;/tr>
&lt;/table>
&lt;p>Case C would fail a CQL parser. So we need to signal to the Search Web Service that this is not a CQL string. And that’s where the “queryType” parameter comes in. If it’s set to “cql” then the query string is to be parsed as CQL, otherwise it must be handled in an alternate fashion. (As of now there is no value set for this parameter that I am aware of so I am using the terms “plain” and “cql” to differentiate.)&lt;/p>
&lt;p>How this should be handled by a CQL aware application is not immediately obvious. My first thought was to allow the application to silently quote such a string but that would change the semantics. It would be better to split the string into separate search clauses for each word and to join the search cluases by a default boolean operator, e.g. “&lt;code>AND&lt;/code>“, so that case C in the table might be interpreted by the application as:&lt;/p>
&lt;p>&lt;blockqoute>``[&lt;strong>Update - 2009.06.07:&lt;/strong> As pointed out by Todd Carpenter of NISO (see comments below) the phrase “&lt;em>SRU by contrast is an initiative to update Z39.50 for the Web&lt;/em>” is inaccurate. I should have said “&lt;em>By contrast SRU is an initiative recognized by ZING (Z39.50 International Next Generation) to bring Z39.50 functionality into the mainstream Web&lt;/em>“.]&lt;/p>
&lt;p>[&lt;strong>Update - 2009.06.08:&lt;/strong> Bizarrely I find in mentioning query languages below that I omitted to mention SQL. I don’t know what that means. Probably just that there’s no Web-based API. And that again it’s tied to a particular technology - RDBMS.]&lt;/p>
&lt;p>&lt;a href="https://www-crossref-org.pluma.sjfc.edu/wp/blog/images/queryType.png">&lt;img alt="queryType.png" src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/images/queryType.png" width="379" height="261" border="0" />&lt;/a>&lt;/p>
&lt;p>(Click image to enlarge.)&lt;/p>
&lt;p>There are two well-known public search APIs for generic Web-based search: &lt;a href="http://www.opensearch.org/" target="_blank">OpenSearch&lt;/a> and &lt;a href="http://www.loc.gov/standards/sru/" target="_blank">SRU&lt;/a>. (Note that the key term here is “generic”, so neither &lt;a href="http://lucene.apache.org/solr/" target="_blank">Solr&lt;/a>/&lt;a href="http://lucene.apache.org/" target="_blank">Lucene&lt;/a> nor &lt;a href="http://www.w3.org/XML/Query/" target="_blank">XQuery&lt;/a> really qualify for that slot. Also, I am concentrating here on “classic” query languages rather than on semantic query languages such as &lt;a href="http://www.w3.org/2009/sparql/wiki/Main_Page" target="_blank">SPARQL&lt;/a>.)&lt;/p>
&lt;p>OpenSearch was created by Amazon’s &lt;a href="https://web.archive.org/web/20090610223844/http://a9.com/" target="_blank">A9.com&lt;/a> and is a cheap and cheerful means to interface to a search service by declaring a template URL and returning a structured XML format. It therefore allows for structured result sets while placing no constraints on the query string. As outlined in my earlier post &lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/search-web-service">Search Web Service&lt;/a>, there is support for search operation control parameters (pagination, encoding, etc.), but no inroads are made into the query string itself which is regarded as opaque.&lt;/p>
&lt;p>SRU by contrast is an initiative to update &lt;a href="http://www.loc.gov/z3950/agency/" target="_blank">Z39.50&lt;/a> for the Web and is firmly focussed on structured queries and responses. Specifically a query can be expressed in the high-level query language &lt;a href="http://www.loc.gov/standards/sru/specs/cql.html" target="_blank">CQL&lt;/a> which is independent of any underlying implementation. Result records are returned using any declared W3C XML Schema format and are transported within a defined XML wrapper format for SRU. (Note that the &lt;a href="https://www.oasis-open.org/committees/documents.php?wg_abbrev=search-ws" target="_blank">SRU 2.0 draft&lt;/a> provides support for arbitrary result formats based on media type.)&lt;/p>
&lt;p>One can summarize the respective OpenSearch and SRU functionalities as in this table:&lt;/p>
&lt;table border="1" width="50%">
&lt;tr>
&lt;th width="33%" align="left">
Structure
&lt;/th>
&lt;pre>&lt;code>&amp;lt;th width=&amp;quot;33%&amp;quot; align=&amp;quot;center&amp;quot;&amp;gt;
OpenSearch
&amp;lt;/th&amp;gt;
&amp;lt;th width=&amp;quot;33%&amp;quot; align=&amp;quot;center&amp;quot;&amp;gt;
SRU
&amp;lt;/th&amp;gt;
&lt;/code>&lt;/pre>
&lt;/tr>
&lt;tr>
&lt;td>
query
&lt;/td>
&lt;pre>&lt;code>&amp;lt;td align=&amp;quot;center&amp;quot;&amp;gt;
no
&amp;lt;/td&amp;gt;
&amp;lt;td align=&amp;quot;center&amp;quot;&amp;gt;
yes
&amp;lt;/td&amp;gt;
&lt;/code>&lt;/pre>
&lt;/tr>
&lt;tr>
&lt;td>
results
&lt;/td>
&lt;pre>&lt;code>&amp;lt;td align=&amp;quot;center&amp;quot;&amp;gt;
yes
&amp;lt;/td&amp;gt;
&amp;lt;td align=&amp;quot;center&amp;quot;&amp;gt;
yes
&amp;lt;/td&amp;gt;
&lt;/code>&lt;/pre>
&lt;/tr>
&lt;tr>
&lt;td>
control
&lt;/td>
&lt;pre>&lt;code>&amp;lt;td align=&amp;quot;center&amp;quot;&amp;gt;
yes
&amp;lt;/td&amp;gt;
&amp;lt;td align=&amp;quot;center&amp;quot;&amp;gt;
yes
&amp;lt;/td&amp;gt;
&lt;/code>&lt;/pre>
&lt;/tr>
&lt;tr>
&lt;td>
diagnostics
&lt;/td>
&lt;pre>&lt;code>&amp;lt;td align=&amp;quot;center&amp;quot;&amp;gt;
no
&amp;lt;/td&amp;gt;
&amp;lt;td align=&amp;quot;center&amp;quot;&amp;gt;
yes
&amp;lt;/td&amp;gt;
&lt;/code>&lt;/pre>
&lt;/tr>
&lt;/table>
&lt;p>What I wanted to discuss here was the OpenSearch and SRU interfaces to a &lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/search-web-service">Search Web Service&lt;/a> such as outlined in my previous post. The &lt;a href="https://www-crossref-org.pluma.sjfc.edu/wp/blog/images/queryType.png">diagram&lt;/a> at top of this post shows query forms for OpenSearch and SRU and associated result types. The Search Web Service is taken to be exposing an SRU interface. It might be simplest to walk through each of the cases.&lt;/p>
&lt;p>(Continues below.)&lt;/p>
&lt;!--more-->
&lt;p>&lt;em>Case 1: OpenSearch (Native Client)&lt;/em>&lt;/p>
&lt;p>As noted, OpenSearch uses a URL template (declared in an OpenSearch description document) where recognized parameters are mapped to implementation-specific parameters. The bolded parameter “&lt;strong>query&lt;/strong>” in the figure indicates an OpenSearch parameter “&lt;strong>searchTerms&lt;/strong>” which has been mapped to the Search Web Service parameter “&lt;strong>query&lt;/strong>“,&lt;/p>
&lt;p>As also noted, SRU 2.0 offers support for alternate result formats (other than SRU XML) by allowing a media type (aka mime type) to be passed in an “http:accept” parameter. There is, however, no OpenSearch parameter corresponding to a format selector, so this must be hard coded directly into the URL template with a value of “application/rss+xml” - the standard media type for an RSS feed which is the common result format for OpenSearch.&lt;/p>
&lt;p>(In the diagram I have noted in parentheses that RSS in its RSS 1.0 form is RDF. And that format is a strong candidate for semantic interoperability. An alternate format would be Atom, which could be similarly selected with a value of “application/atom+xml”, but it is difficult to see at this time what advantage Atom confers. It does not conform to the RDF data model but may find better support in code libraries and applications.)&lt;/p>
&lt;p>The third parameter shown for Case 1, is “queryType” which is another new SRU 2.0 parameter. I had noted earlier that an OpenSearch query string could be passed directly through to the Search Web Service and its associated CQL parser. It tuns out that this needs to be analyzed further. (And many thanks to Jonathan Rochkind for useful discussions on this.)&lt;/p>
&lt;p>I had naively assumed that an OpenSearch query string would either be packed as a CQL string or would be a simple text string which could be interpreted as CQL. The latter interpretation (text string) turns out to be true only for a single bare word or for a quoted string - both of which are recognized CQL query strings (i.e. a single search term which has a default index and relationship to that index). It fails, however, for the more general case of unquoted strings. See table below for these cases.&lt;/p>
&lt;table border="1" width="50%">
&lt;tr>
&lt;th width="50%">
Query type
&lt;/th>
&lt;pre>&lt;code>&amp;lt;th width=&amp;quot;50%&amp;quot;&amp;gt;
Query string
&amp;lt;/th&amp;gt;
&lt;/code>&lt;/pre>
&lt;/tr>
&lt;tr>
&lt;td>
A. bare word
&lt;/td>
&lt;pre>&lt;code>&amp;lt;td align=&amp;quot;left&amp;quot;&amp;gt;
this
&amp;lt;/td&amp;gt;
&lt;/code>&lt;/pre>
&lt;/tr>
&lt;tr>
&lt;td>
B. quoted string
&lt;/td>
&lt;pre>&lt;code>&amp;lt;td align=&amp;quot;left&amp;quot;&amp;gt;
&amp;amp;#8220;this is a query&amp;amp;#8221;
&amp;lt;/td&amp;gt;
&lt;/code>&lt;/pre>
&lt;/tr>
&lt;tr>
&lt;td>
C. unquoted string
&lt;/td>
&lt;pre>&lt;code>&amp;lt;td align=&amp;quot;left&amp;quot;&amp;gt;
this is a query
&amp;lt;/td&amp;gt;
&lt;/code>&lt;/pre>
&lt;/tr>
&lt;/table>
&lt;p>Case C would fail a CQL parser. So we need to signal to the Search Web Service that this is not a CQL string. And that’s where the “queryType” parameter comes in. If it’s set to “cql” then the query string is to be parsed as CQL, otherwise it must be handled in an alternate fashion. (As of now there is no value set for this parameter that I am aware of so I am using the terms “plain” and “cql” to differentiate.)&lt;/p>
&lt;p>How this should be handled by a CQL aware application is not immediately obvious. My first thought was to allow the application to silently quote such a string but that would change the semantics. It would be better to split the string into separate search clauses for each word and to join the search cluases by a default boolean operator, e.g. “&lt;code>AND&lt;/code>“, so that case C in the table might be interpreted by the application as:&lt;/p>
&lt;p>&lt;blockqoute>`` &lt;/blockquote>&lt;/p>
&lt;p>Now, of course, we must not expect that a typical OpenSearch implementation would be aware of CQL (or any of the SRU technologies). Instead we can simply indicate in the URL template that the “queryType” is non-CQL, by hard coding “queryType=plain”. The actual URL template which is declared in the OpenSearch description would thus be something like the following (with whitespace added for clarity):&lt;/p>
&lt;pre>&amp;lt;!-- 1. queryType="plain" --&amp;gt;
&amp;lt;Url type="application/rss+xml"
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;template="http://www.example/search?
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;query={&lt;b>searchTerms&lt;/b>}
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;queryType=plain
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;http:accept=application/rss+xml
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;"
/&amp;gt;
&lt;/pre>
&lt;p>This URL template uses one OpenSearch parameter(“searchTerms”) and that is mapped to the SRU parameter “query”. The SRU 2.0 parameters “queryType” and “http:accept” are wired in. This means that a Search Web Service would be aware of the query, would know that it was not CQL (so might invoke a handler), and would be know that a result set in RSS was required.&lt;/p>
&lt;p>&lt;em>Case 2: OpenSearch (CQL-Aware Client)&lt;/em>&lt;/p>
&lt;p>The above case, works for a general OpenSearch client but now is problematic for a CQL-aware client. With the “queryType” set at “plain” there is no opportunity to indicate that a generic CQL string might be passed instead. We certainly wouldn’t want a non-CQL handler to operate on a valid CQL string. We need to vary the SRU 2.0 parameters and within the scope of OpenSearch this can only be done by recognizing the parameters as &lt;a href="https://opensearch.org/blog/introducing-extensions-for-opensearch/" target="_blank">OpenSearch extensions&lt;/a>. Basically, an extension is nothing more than a separately namespaced element or attribute. Recommendation is that the XML namespace would resolve to a specification document detailing the intention and format of the extension.&lt;/p>
&lt;p>The URL template for a CQL-aware OpenSearch description could make use of the “queryType” and “http:accept” parameters as OpenSearch extensions (marked in bold italics in the figure) using a declaration like this:&lt;/p>
&lt;pre>&amp;lt;!-- 2. queryType="cql" --&amp;gt;
&amp;lt;Url type="application/xml"
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;xmlns:sru="http://opensearch.example/sru-extension"
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;template="http://www.example/search?
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;query={&lt;b>searchTerms&lt;/b>}
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;queryType={&lt;b>sru:queryType?&lt;/b>}
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;http:accept={&lt;b>sru:httpAccept?&lt;/b>}
&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;"
/&amp;gt;
&lt;/pre>
&lt;p>Note here that both parameters have been specified as being optional. Also the namespace here is pointed at a fictional OpenSearch extension document. (It doesn’t need to point to such a document - could be anything - but it is recommended that there be a specification.)&lt;/p>
&lt;p>I’m not aware of any such OpenSearch extension document for SRU currently existing but would be prepared to contribute to drafting such a document. It seems to me that it would be would be very useful for general OpenSearch/SRU compatibility and probably should detail all the SRU 2.0 parameters for “searchRetrieve”. In fact, that document could be the SRU spec itself, once that was established at a fixed URL. (Whether there should be a specific OpenSearch extension document depends on whether it would be useful to provide OpenSearch implementation details.)&lt;/p>
&lt;p>&lt;em>Case 3: SRU (Native Client)&lt;/em>&lt;/p>
&lt;p>This is easy. We’re on home ground now. The query type is by default CQL, and the result format is SRU XML. The only thing that might be specified is “recordSchema” to require a schema for the result records, if there are alternate schemas supported by the Search Web Service. A default for the result records is anyway supplied.&lt;/p>
&lt;p>&lt;em>Case 4: SRU (Media-Typed Client)&lt;/em>&lt;/p>
&lt;p>Again, we’re on familiar ground. For a media-savvy SRU interface we would need to use the SRU 2.0 parameter “http:accept”. This could be used to override the default SRU XML with an alternate format, e.g. RSS.&lt;/p>
&lt;p>And that’s about it for this review of aligning the OpenSearch and SRU interfaces. It seems that using URL templates and OpenSearch extensions as indicated should allow for an easy OpenSearch interface onto an SRU-based Search Web Service. At a minimum we just need a permanent URL for the SRU 2.0 spec (when finalized). Alternately a separate OpenSearch extension document could be drafted and registered. That would allow for details specific to OpenSearch to be provided, as well as bringing SRU closer into the OpenSearch realm. And such a document could be created now and updated with the URL for the SRU 2.0 spec as it progresses from draft to final.&lt;/p></description></item><item><title>Search Web Service</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/search-web-service/</link><pubDate>Sat, 30 May 2009 00:00:00 +0000</pubDate><author>Tony Hammond</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/search-web-service/</guid><description>&lt;p>&lt;a href="https://www-crossref-org.pluma.sjfc.edu/wp/blog/images/search-web-service.png">&lt;img alt="search-web-service.png" src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/images/search-web-service.png" width="405" height="303" border="0" />&lt;/a>&lt;/p>
&lt;p>(Click image to enlarge graphic.)&lt;/p>
&lt;p>While the &lt;a href="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=search-ws" target="_blank">OASIS Search Web Services TC&lt;/a> is currently working towards reconciling SRU and OpenSearch, I thought it would be useful to share here a simple graphic outlining how a search web service for structured search might be architected.&lt;/p>
&lt;p>Basically there are two views of this search web service (described in separate XML description files and discoverable through autodiscovery links added to HTML pages):&lt;/p>
&lt;ul>
&lt;li>&lt;a href="http://www.opensearch.org/" target="_blank">OpenSearch&lt;/a>
&lt;ul>
&lt;li>
&lt;p>&lt;a href="http://www.loc.gov/standards/sru/" target="_blank">SRU (Search and Retrieve by URL)&lt;/a>&lt;/ul>
One can see at a glance that there’s more happening down in the SRU layer. The SRU layer implements a heavyweight, robust service which provides a detailed listing of search indexes and index relations in the description document (‘SRU Explain’), is searchable using a standard query grammar - &lt;a href="http://www.loc.gov/standards/sru/specs/cql.html" target="_blank">CQL&lt;/a> (‘Contextual Query Language’), responds with result sets inside a standard XML wrapper and expressed as an XML record set (e.g. PAM) that is validatable using W3C XML Schema, and makes available a full roster of diagnostics.&lt;/p>
&lt;p>By contrast the OpenSearch layer provides a lightweight view onto the search web service in which a simple opaque query string is sent to the server and a simple XML result set returned (usually RSS or Atom). Again a description document is made available (‘OpenSearch Description’) but this is much more coarse grained than the SRU description - e.g. it does not specify query components such as indexes or relations.&lt;/p>
&lt;p>In practice, both views can be provided for by the same search web service. While OpenSearch does not specify any structured query it can make use of a CQL packaged query. That is, a single parameter value for the OpenSearch ‘query’ parameter can be unpacked by a CQL parser to yield a complex search query. The search query does not need to be splattered all over the URL querystring which is already using its parameter set to provide control information for the search (e.g. pagination, encoding and the like).&lt;/p>
&lt;p>And how would this relate to existing platform-hosted search services? Well, such services are usually bound to the host platform and are not intended to support remote applications. A search web service, on the other hand, would be ideally suited to offering direct support for running structured searches on platform-hosted content using off-platform apps.&lt;/p>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul></description></item><item><title>Structured Search Using PRISM Elements</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/structured-search-using-prism-elements/</link><pubDate>Sat, 30 May 2009 00:00:00 +0000</pubDate><author>Tony Hammond</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/structured-search-using-prism-elements/</guid><description>&lt;p>We just registered in the &lt;a href="http://www.loc.gov/standards/sru/" target="_blank">SRU&lt;/a> (Search and Retrieve by URL) search registry the following components:&lt;/p>
&lt;dl>
&lt;dt>&lt;strong>&lt;em>Context Sets&lt;/em>&lt;/strong>&lt;/p>&lt;/dt>
&lt;dd>&lt;ul>
&lt;li>&lt;a href="http://www.loc.gov/standards/sru/cql/contextSets/prism-context-set-v2-0.html" target="_blank">PRISM Context Set version 2.0&lt;/a>
&lt;ul>
&lt;li>
&lt;dl>
&lt;dt>&lt;a href="http://www.loc.gov/standards/sru/cql/contextSets/prism-context-set-v2-1.html" target="_blank">PRISM Context Set version 2.1&lt;/a>&lt;/ul>&lt;/dt>
&lt;dt>&lt;strong>&lt;em>Schemas&lt;/em>&lt;/strong>&lt;/p>&lt;/dt>
&lt;dd>
&lt;ul>
&lt;li>PRISM Aggregator Message Record Schema Version 2.0
&lt;ul>
&lt;li>
&lt;p>PRISM Aggregator Message Record Schema Version 2.1&lt;/ul> &lt;/dl>
This means that an &lt;a href="http://www.loc.gov/standards/sru/" target="_blank">SRU&lt;/a> (Search and Retrieve by URL) search engine that supported one of the PRISM context sets registered above could accept &lt;a href="http://www.loc.gov/standards/sru/specs/cql.html" target="_blank">CQL&lt;/a> (Contextual Query Language) queries such as the following:&lt;/p>
&lt;ol>
&lt;li>&lt;tt>prism.doi = &amp;ldquo;10.1038/nature05398&amp;rdquo;&lt;/tt>
&lt;ul>
&lt;li>&lt;tt>prism.publicationName = &amp;ldquo;Nature&amp;rdquo; and prism.volume = &amp;ldquo;444&amp;rdquo; and prism.number = &amp;ldquo;7119&amp;rdquo; and prism.startingPage = &amp;ldquo;E9&amp;rdquo;&lt;/tt>
&lt;ul>
&lt;li>&lt;tt>dc.identifier = &amp;ldquo;doi:10.1038/nature05398&amp;rdquo;&lt;/tt>
&lt;ul>
&lt;li>&lt;tt>dc.creator = &amp;ldquo;Jones-Smith&amp;rdquo; and prism.publicationName = &amp;ldquo;Nature&amp;rdquo; and prism.publicationDate &amp;gt; &amp;ldquo;2006-01-01&amp;rdquo;&lt;/tt>
&lt;ul>
&lt;li>&lt;tt>dc.title any &amp;ldquo;fractal pollock&amp;rdquo; and prism.publicationName = &amp;ldquo;Nature&amp;rdquo; sortBy prism.publicationDate/sort.descending&lt;/tt>
&lt;ul>
&lt;li>
&lt;p>&lt;tt>&amp;ldquo;fractal anlysis&amp;rdquo; and prism.publicationDate within &amp;ldquo;2005-01-01 2008-12-31&amp;rdquo; sortBy dc.creator/sort.ascending&lt;/tt>&lt;/ol>
(Note that the quotes are only needed above for the DOI strings which contain a “/” character. Otherwise they are optional in the above examples.)&lt;/p>
&lt;p>Any query such as one of the above (here #1) could be sent to the server on a querystring like so:&lt;/p>&lt;/p>
&lt;blockquote>
&lt;p>&lt;tt>?version=1.1&amp;amp;operation=searchRetrieve&amp;amp;query=prism.doi=%2210.1038/nature05398%22&lt;/tt>&lt;/p>
&lt;/blockquote>
&lt;p>and if the server were also equipped to respond with &lt;a href="https://www.idealliance.org/pam" target="_blank">PAM&lt;/a> (PRISM Aggregator Message) format for result records, a response might look like this:&lt;/p>
&lt;img alt="fractal-analysis-pam.jpg" src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/images/fractal-analysis-pam.jpg" width="686" height="450" />
&lt;p>PAM was discussed &lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/prism-aggregator-message/">here&lt;/a> earlier.&lt;/p>
Such a structured response would provide the metadata elements for applications to build various interfaces into the original article:&lt;/p>
&lt;img alt="fractal-analysis.jpg" src="https://www-crossref-org.pluma.sjfc.edu/wp/blog/images/fractal-analysis.jpg" width="459" height="401" />
&lt;p>We think that these PRISM components (context sets and schemas) will be useful for structured search of scholarly publications.&lt;/p>&lt;/p>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ol>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul>
&lt;/dd>
&lt;/dl>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul>
&lt;/dd>
&lt;/dl></description></item><item><title>Search Web Services - New Committee Drafts</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/search-web-services-new-committee-drafts/</link><pubDate>Tue, 29 Jul 2008 00:00:00 +0000</pubDate><author>Tony Hammond</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/search-web-services-new-committee-drafts/</guid><description>&lt;p>As posted &lt;a href="http://listserv.loc.gov/cgi-bin/wa?A2=ind0807&amp;amp;#038;L=zng&amp;amp;#038;T=0&amp;amp;#038;P=52" target="_blank">here&lt;/a> on the &lt;a href="https://web.archive.org/web/20130303230855/http://sun8.loc.gov/listarch/zng.html" target="_blank">SRU Implementors&lt;/a> list, the &lt;a href="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=search-ws" target="_blank">OASIS Search Web Services Technical Committee&lt;/a> has announced the release of five Committee Drafts, informally known as:&lt;/p>
&lt;ol>
&lt;li>&lt;a href="http://docs.oasis-open.org/search-ws/v1.0/apd-V1.0.html" target="_blank">Abstract Protocol Definition  (APD)&lt;/a>
&lt;ul>
&lt;li>&lt;a href="http://docs.oasis-open.org/search-ws/v1.0/sru-1-2-V1.0.html" target="_blank">Binding for SRU 1.2&lt;/a>
&lt;ul>
&lt;li>&lt;a href="http://docs.oasis-open.org/search-ws/v1.0/binding-for-get-V1.0.html" target="_blank">Auxiliary Binding for HTTP GET&lt;/a>
&lt;ul>
&lt;li>&lt;a href="http://docs.oasis-open.org/search-ws/v1.0/cql-1-2-v1.0.html" target="_blank">CQL 1.2&lt;/a>
&lt;ul>
&lt;li>
&lt;p>&lt;a href="http://docs.oasis-open.org/search-ws/v1.0/opensearch-v1.0.html" target="_blank">Binding for OpenSearch&lt;/a>&lt;/ol>
Links to specific document formats are given at the bottom of the mail. A list of the TC public documents is also available &lt;a href="https://www.oasis-open.org/committees/documents.php?wg_abbrev=search-ws" target="_blank">here&lt;/a>.&lt;/p>
&lt;p>The next phase of work for the TC will be the development of SRU/CQL 2.0, and the Description Language.&lt;/p>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ol></description></item><item><title>Robots: One Standard Fits All</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/robots-one-standard-fits-all/</link><pubDate>Wed, 04 Jun 2008 00:00:00 +0000</pubDate><author>Tony Hammond</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/robots-one-standard-fits-all/</guid><description>&lt;p>Interesting &lt;a href="https://web.archive.org/web/20080630064024/http://www.ysearchblog.com/archives/000587.html" target="_blank">post&lt;/a> from Yahoo! Search’s Director of Product Management, Priyank Garg, “&lt;em>One Standard Fits All: Robots Exclusion Protocol for Yahoo!, Google and Microsoft&lt;/em>“. Interesting also for what it doesn’t talk about. No mention here of &lt;a href="https://web.archive.org/web/20080514202201/http://the-acap.org/" target="_blank">ACAP&lt;/a>.&lt;/p></description></item><item><title>On Google Knol</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/on-google-knol/</link><pubDate>Fri, 14 Dec 2007 00:00:00 +0000</pubDate><author>Crossref</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/on-google-knol/</guid><description>&lt;p>The recently discussed (announced?) &lt;a href="https://web.archive.org/web/20210926222403/https://googleblog.blogspot.com/2007/12/encouraging-people-to-contribute.html" target="_blank">Google Knol&lt;/a> project could make Google Scholar look like a tiny blip in the the scholarly publishing landscape.&lt;/p>
&lt;p>I love the comment an authority:&lt;/p>
&lt;p>“Books have authors’ names right on the cover, news articles have bylines, scientific articles always have authors — but somehow the web evolved without a strong standard to keep authors names highlighted. We believe that knowing who wrote what will significantly help users make better use of web content.”&lt;/p>
&lt;p>And so I suppose this means they are assigning author identifiers….&lt;/p></description></item><item><title>Search Web Services Document</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/search-web-services-document/</link><pubDate>Fri, 09 Nov 2007 00:00:00 +0000</pubDate><author>Tony Hammond</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/search-web-services-document/</guid><description>&lt;p>The OASIS Search Web Services TC has just put out the following document for public review (Nov 7- Dec 7, 2007):&lt;/p>
&lt;blockquote>
&lt;p>_Search Web Services v1.0 Discussion Document&lt;/p>&lt;/p>
&lt;ul>
&lt;li>Editable Source: &lt;a href="http://docs.oasis-open.org/search-ws/v1.0/DiscussionDocument.doc" target="_blank">http://docs.oasis-open.org/search-ws/v1.0/DiscussionDocument.doc&lt;/a>
&lt;ul>
&lt;li>PDF: &lt;a href="http://docs.oasis-open.org/search-ws/v1.0/DiscussionDocument.pdf" target="_blank">http://docs.oasis-open.org/search-ws/v1.0/DiscussionDocument.pdf&lt;/a>
&lt;ul>
&lt;li>
&lt;p>HTML: &lt;a href="http://docs.oasis-open.org/search-ws/v1.0/DiscussionDocument.html" target="_blank">http://docs.oasis-open.org/search-ws/v1.0/DiscussionDocument.html&lt;/a> &lt;/ul>
&lt;/i>&lt;/blockquote>&lt;/p>
&lt;p>From the OASIS announcement:&lt;/p>
&lt;blockquote>
&lt;p>&lt;em>“This document: “Search Web Services Version 1.0 - Discussion Document - 2 November 2007”, was prepared by the OASIS Search Web Services TC as a strawman proposal, for public review, intended to generate discussion and interest. It has no official status; it is not a Committee Draft. The specification is based on the SRU (Search Retrieve via URL) specification which can be found at &lt;a href="http://www.loc.gov/standards/sru/" target="_blank">http://www.loc.gov/standards/sru/&lt;/a>. It is expected that this standard, when published, will deviate from SRU. How much it will deviate cannot be predicted at this time. The fact that the SRU spec is used as a starting point for development should not be cause for concern that this might be an effort to rubberstamp or fasttrack SRU. The committee hopes to preserve the useful features of SRU, eliminate those that are not considered useful, and add features that are not in SRU but are considered useful. “&lt;/em>&lt;/p>
&lt;/blockquote>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul>
&lt;/li>
&lt;/ul>
&lt;/blockquote></description></item><item><title>ACAP - Any chance of success?</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/acap-any-chance-of-success/</link><pubDate>Wed, 19 Sep 2007 00:00:00 +0000</pubDate><author>Ed Pentz</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/acap-any-chance-of-success/</guid><description>&lt;p>ACAP has released &lt;a href="https://web.archive.org/web/20071007123940/http://www.the-acap.org/project-documents.php" target="_blank">some documents&lt;/a> outlining the use cases they will be testing and some proposed changes to the Robots Exclusion Protocol (REP) - both robots.txt and META tags. There are some very practical proposals here to improve search engine indexing. However, the only search engine publicly participating in the project is &lt;a href="http://www.exalead.com/" target="_blank">http://www.exalead.com/&lt;/a> (which according to Alexa attracted 0.0043% of global internet visits over the last three months). The main docs are “ACAP pilot Summary use cases being tested”, “ACAP Technical Framework - Robots Exclusion Protocol - strawman proposals Part 1”, “ACAP Technical Framework - Robots Exclusion Protocol - strawman proposals Part 2”, “ACAP Technical Framework - Usage Definitions - draft for pilot testing”.&lt;/p>
&lt;p>What would cause other search engines to recognize the ACAP protocols rather than ignore them? A lot of publishers implementing this and requiring search engines to recognize it to index content could put pressure on the engines. Maybe.&lt;/p></description></item><item><title>New SRU (1.2) Website</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/new-sru-1.2-website/</link><pubDate>Wed, 08 Aug 2007 00:00:00 +0000</pubDate><author>Tony Hammond</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/new-sru-1.2-website/</guid><description>&lt;p>From Ray Denenberg’s post to the &lt;a href="https://web.archive.org/web/20070813010703/http://www.loc.gov/standards/sru/community/listserv.html" target="_blank">SRU Listserv&lt;/a> yesterday:&lt;/p>
&lt;blockquote>
&lt;p>_“The new SRU web site is now up: &lt;a href="http://www.loc.gov/sru/" target="_blank">http://www.loc.gov/sru/&lt;/a>&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>It is completely reorganized and reflects the version 1.2 specifications.&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>(It also includes version 1.1 specifications, but is oriented to version&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>1.2.)&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>…&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>There is an official 1.1 archive under the new site,&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>&lt;a href="https://web.archive.org/web/20080724063403/http://www.loc.gov/sru/sru1-1archive/" target="_blank">https://web.archive.org/web/20080724063403/http://www.loc.gov/sru/sru1-1archive/&lt;/a>. And note also, that the new spec incorporates both version 1.1 and 1.2 (anything specific to version 1.1 is annotated as such).”_&lt;/p>
&lt;/blockquote>
&lt;p>Interested to learn if any Crossref publishers are currently implementing SRU.&lt;/p></description></item><item><title>OASIS Announces Search Web Services TC</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/oasis-announces-search-web-services-tc/</link><pubDate>Fri, 15 Jun 2007 00:00:00 +0000</pubDate><author>Tony Hammond</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/oasis-announces-search-web-services-tc/</guid><description>&lt;p>&lt;a href="https://www.oasis-open.org/" target="_blank">OASIS&lt;/a> has just &lt;a href="http://lists.oasis-open.org/archives/tc-announce/200706/msg00008.html" target="_blank">announced&lt;/a> a technical committee for standardising search services. This from the Call for Participation:&lt;/p>
&lt;blockquote>
&lt;p>_&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>b. Purpose&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>To define Search and Retrieval Web Services, combining various current and&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>ongoing web service activities.&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>Within recent years there has been a growth in activity in the development of&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>web service definitions for search and retrieval applications. These include&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>SRU, a web service based in part on the NISO/ISO Search and Retrieval standards;&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>the Amazon OpenSearch, which defines a means of describing and automating search&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>web forms; as well as many proprietary definitions (e.g. the Google and MSN&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>Search APIs). There are also a number of activities for defining abstract search&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>APIs that can be mapped onto multiple implementations either within native code&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>or onto remote procedural calls and web services, such as ZOOM (Z39.50 Object&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>Oriented Model); SQI (Simple Query Interface), an IEEE standard developed for&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>searching and retrieval in the IMS (Instructional Management Systems) space; and&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>OSIDs (Open Service Interface Definitions from the Open Knowledge Initiative.&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>While abstract APIs would be out of scope, these would inform the work to&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>increase interoperability and compatibility.&lt;/p>
&lt;/blockquote>
&lt;blockquote>
&lt;p>_&lt;/p>
&lt;/blockquote></description></item><item><title>&amp;#8220;We’re sorry&amp;#8230;&amp;#8221;</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/%238220were-sorry%238230%238221/</link><pubDate>Mon, 19 Feb 2007 00:00:00 +0000</pubDate><author>Tony Hammond</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/%238220were-sorry%238230%238221/</guid><description>&lt;p>&lt;strong>Update:&lt;/strong> All apologies to Google. Apparently this was a problem at our end which our IT folks are currently investigating. (And I thought it was just me. 🙂&lt;/p>
&lt;p>Just managed to get this page:&lt;/p>
&lt;p>_“Google Error&lt;/p>
&lt;p>We’re sorry…&lt;/p>
&lt;p>… but your query looks similar to automated requests from a computer virus or spyware application. To protect our users, we can’t process your request right now.&lt;/p>
&lt;p>We’ll restore your access as quickly as possible, so try again soon. In the meantime, if you suspect that your computer or network has been infected, you might want to run a virus checker or spyware remover to make sure that your systems are free of viruses and other spurious software.&lt;/p>
&lt;p>We apologize for the inconvenience, and hope we’ll see you again on Google.&lt;/p>
&lt;p>To continue searching, please type the characters you see below:”_&lt;/p>
&lt;p>And my search request?&lt;/p>
&lt;p>&lt;tt>ark&lt;/tt>&lt;/p>
&lt;p>(Actual query is &lt;a href="http://www.google.com/sorry/?continue=http://www.google.com/search%3Fclient%3Dfirefox-a%26rls%3Dorg.mozilla%253Aen-US%253Aofficial%26channel%3Ds%26hl%3Den%26q%3Dark%26btnG%3DGoogle%2BSearch" target="_blank">here&lt;/a> as argument to the &lt;tt>continue&lt;/tt> parameter.)&lt;/p>
&lt;p>Was hoping to find results related to the &lt;a href="http://www.ietf.org/internet-drafts/draft-kunze-ark-12.txt" target="_blank">The ARK Persistent Identifier Scheme&lt;/a>. Maybe I missed something but I’m not impressed.&lt;/p></description></item><item><title>SearchULike</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/searchulike/</link><pubDate>Mon, 05 Feb 2007 00:00:00 +0000</pubDate><author>Tony Hammond</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/searchulike/</guid><description>&lt;p>Nelson Minar has a short &lt;a href="http://www.somebits.com/weblog/tech/bad/googleSearchHistory.html" target="_blank">post&lt;/a> on Google’s &lt;a href="http://www.google.com/searchhistory" target="_blank">Search History&lt;/a> ‘feature’ and how it can be used to enhance your search experience. I guess that should be SearchULike.&lt;/p></description></item><item><title>Google offer on journal archives</title><link>https://www-crossref-org.pluma.sjfc.edu/blog/google-offer-on-journal-archiv-1/</link><pubDate>Mon, 18 Dec 2006 00:00:00 +0000</pubDate><author>Ed Pentz</author><guid>https://www-crossref-org.pluma.sjfc.edu/blog/google-offer-on-journal-archiv-1/</guid><description>&lt;p>Peter Suber &lt;a href="http://www.earlham.edu/~peters/fos/2006_12_17_fosblogarchive.html#116637929327063772" target="_blank">reports&lt;/a> on his Open Access News that Google is offering to digitize journal backfiles. The full text articles are available as images and for free hosted by Google. The deal is non-exclusive and publishers retain copyright (but many backfiles will be out of copyright) but Google will not supply the publisher with the electronic files - so non-exclusive means that the publisher or someone else could digitize the back-year records too (but how to recover the costs when it’s all free in Google?).&lt;/p>
&lt;p>Dorothea Salo (&lt;a href="https://www-crossref-org.pluma.sjfc.edu/blog/speaking-of-stm-innovations/">recent STM Innovations speaker&lt;/a>) over at Caveat Lector provides an excellent &lt;a href="https://web.archive.org/web/20080725070901/http://cavlec.yarinareth.net/archives/2006/12/17/control-your-bits/" target="_blank">review of the Google offer&lt;/a> with some good advice for publishers (“always control your bits”).&lt;/p></description></item></channel></rss>