Difference between revisions of "CC OpenSearch"
(→OpenSearch Description Document) |
m (→See Also) |
||
(10 intermediate revisions by the same user not shown) | |||
Line 11: | Line 11: | ||
<code>Attribution</code> and <code>SyndicationRights</code> elements are ''not'' relevant -- they describe search results, not the content referred to by search results. | <code>Attribution</code> and <code>SyndicationRights</code> elements are ''not'' relevant -- they describe search results, not the content referred to by search results. | ||
− | How should a CC-enabled search engine describe itself? | + | How should a CC-enabled search engine describe itself? Three options: |
− | * Multiple descriptions, one corresponding to each filter services wishes to expose, e.g., one of four for each of the examples [[CcSearch_integration here]], specifically four OpenSearch Description Documents, each with a Url element (or elements, corresponding to HTML/RSS/Atom outputs) hardcoding desired filter, like | + | ===CC options as special keywords=== |
+ | |||
+ | Search engines already support many special keyword operators, e.g., <code>link:</code>, <code>site:</code>. | ||
+ | |||
+ | Absolutely no extension of the description document is required to faciliate this use. | ||
+ | |||
+ | Going this route, it would be useful if search services supported a consistent syntax for license restrictions, as many do for link, site, etc. | ||
+ | |||
+ | ===Multiple description documents=== | ||
+ | |||
+ | * Multiple descriptions, one corresponding to each filter services wishes to expose, e.g., one of four for each of the examples [[CcSearch_integration|here]], specifically four OpenSearch Description Documents, each with a <code>Url</code> element (or elements, corresponding to HTML/RSS/Atom outputs) hardcoding desired filter, like | ||
<pre> | <pre> | ||
<nowiki> | <nowiki> | ||
Line 25: | Line 35: | ||
</nowiki> | </nowiki> | ||
</pre> | </pre> | ||
+ | Note that each of these would be in a separate description document; there would be four description documents. | ||
+ | |||
+ | ===Extension with custom parameters=== | ||
+ | |||
+ | [http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_URL_template_syntax URL templates] used in the <code>template</code> attribute of the <code>Url</code> element may have custom parameters. A CC [http://www.opensearch.org/Specifications/OpenSearch/Extensions extension] could define these, or possibly OpenSearch Description Documents could utilize the [http://www.opensearch.org/Specifications/OpenSearch/Extensions/Parameter/1.0 parameter extension] to describe license filter parameters. | ||
− | [http://www.opensearch.org/ | + | An extension approach would be more elegant than a multiple description approach, but may not work well for existing services that may have URL formats difficult to map to parameters for each license attribute one may want to filter on. |
+ | |||
+ | An imaginary CC extension might include the following custom parameters: | ||
+ | |||
+ | <pre> | ||
+ | <nowiki> | ||
+ | {cc:permitsDistribution} | ||
+ | {cc:prohibitsCommercialUse} | ||
+ | {cc:permitsDerivativeWorks} | ||
+ | </nowiki> | ||
+ | </pre> | ||
+ | |||
+ | Others may be useful as well, e.g., | ||
+ | |||
+ | <pre> | ||
+ | <nowiki> | ||
+ | {cc:requiresShareAlike} | ||
+ | {cc:PublicDomain} | ||
+ | {cc:license} | ||
+ | </nowiki> | ||
+ | </pre> | ||
+ | |||
+ | All of the above would presumably expect a boolean value (1/0, true/false), except the last, which might expect a license URL or pattern. | ||
+ | |||
+ | Example use in a <code>Url</code> element: | ||
+ | |||
+ | <pre> | ||
+ | <nowiki> | ||
+ | <Url type="application/atom+xml" template="http://example.com/?q={searchTerms}&cc-distribution={cc:permitsDistribution?}&cc-nocommercial={cc:prohibitsCommercialUse?}&cc-derivs={cc:permitsDerivativeWorks?}"/> | ||
+ | </nowiki> | ||
+ | </pre> | ||
+ | |||
+ | This solution may not be practical. '''How do [http://www.opensearch.org/Community/OpenSearch_enabled_search_clients OpenSearch consumers] handle custom parameters?''' | ||
==OpenSearch Response Elements== | ==OpenSearch Response Elements== | ||
Line 36: | Line 83: | ||
==Todo== | ==Todo== | ||
− | * Determine best practice for using OpenSearch Description Document to | + | ===Open Questions=== |
+ | |||
+ | * Determine best practice for using OpenSearch Description Document to faciliate CC filtered search. | ||
+ | ** Multiple description documents? | ||
+ | ** Extension with custom parameters -- how in practice to OpenSearch consumers deal with custom parameters? | ||
+ | ** CC filters entirely specified in <code>searchTerms</code>. | ||
+ | |||
+ | ===Implementation=== | ||
+ | * Implement best practices in [[CcHost]] | ||
* Encourage search services that support OpenSearch and remember license info for searchable materials to include license annotations in OpenSearch result feeds, per [[Syndication|existing extensions]]. | * Encourage search services that support OpenSearch and remember license info for searchable materials to include license annotations in OpenSearch result feeds, per [[Syndication|existing extensions]]. | ||
Line 42: | Line 97: | ||
* http://www.opensearch.org | * http://www.opensearch.org | ||
* http://en.wikipedia.org/wiki/OpenSearch | * http://en.wikipedia.org/wiki/OpenSearch | ||
− | * [[ | + | * [[CC Search]] -- CC's simple "frame" interface available at http://search.creativecommons.org, unrelated in terms of technology to OpenSearch |
* [[Syndication]] -- license annotations in syndication formats | * [[Syndication]] -- license annotations in syndication formats | ||
[[Category:Search]] | [[Category:Search]] | ||
[[Category:Developer]] | [[Category:Developer]] |
Latest revision as of 18:31, 6 September 2010
"OpenSearch is a collection of simple formats for the sharing of search results."[1]
This page concerns how an OpenSearch supporting search service might indicate that it facilitates queries filtered by license and how results might be annotated with license info.
OpenSearch consists of a format describing a search service and extensions of RSS 2.0 and Atom 1.0 to faciliate returning search results in these syndication formats.
Contents
OpenSearch Description Document
OpenSearch Description Document is a file format for describing a search service that supports OpenSearch.
Attribution
and SyndicationRights
elements are not relevant -- they describe search results, not the content referred to by search results.
How should a CC-enabled search engine describe itself? Three options:
CC options as special keywords
Search engines already support many special keyword operators, e.g., link:
, site:
.
Absolutely no extension of the description document is required to faciliate this use.
Going this route, it would be useful if search services supported a consistent syntax for license restrictions, as many do for link, site, etc.
Multiple description documents
- Multiple descriptions, one corresponding to each filter services wishes to expose, e.g., one of four for each of the examples here, specifically four OpenSearch Description Documents, each with a
Url
element (or elements, corresponding to HTML/RSS/Atom outputs) hardcoding desired filter, like
<Url type="application/rss+xml" template="http://flickr.com/search/?l=cc&q={searchTerms}" /> <Url type="application/rss+xml" template="http://flickr.com/search/?l=comm&q={searchTerms}" /> <Url type="application/rss+xml" template="http://flickr.com/search/?l=deriv&q={searchTerms}" /> <Url type="application/rss+xml" template="http://flickr.com/search/?l=commderiv&q={searchTerms}" />
Note that each of these would be in a separate description document; there would be four description documents.
Extension with custom parameters
URL templates used in the template
attribute of the Url
element may have custom parameters. A CC extension could define these, or possibly OpenSearch Description Documents could utilize the parameter extension to describe license filter parameters.
An extension approach would be more elegant than a multiple description approach, but may not work well for existing services that may have URL formats difficult to map to parameters for each license attribute one may want to filter on.
An imaginary CC extension might include the following custom parameters:
{cc:permitsDistribution} {cc:prohibitsCommercialUse} {cc:permitsDerivativeWorks}
Others may be useful as well, e.g.,
{cc:requiresShareAlike} {cc:PublicDomain} {cc:license}
All of the above would presumably expect a boolean value (1/0, true/false), except the last, which might expect a license URL or pattern.
Example use in a Url
element:
<Url type="application/atom+xml" template="http://example.com/?q={searchTerms}&cc-distribution={cc:permitsDistribution?}&cc-nocommercial={cc:prohibitsCommercialUse?}&cc-derivs={cc:permitsDerivativeWorks?}"/>
This solution may not be practical. How do OpenSearch consumers handle custom parameters?
OpenSearch Response Elements
OpenSearch Response Elements extend syndication formats to faciliate using these to convey search results.
It should be possible to use existing RSS 2.0 and Atom 1.0 license extensions to indicate the licensing of resources referred to in search feeds.
Todo
Open Questions
- Determine best practice for using OpenSearch Description Document to faciliate CC filtered search.
- Multiple description documents?
- Extension with custom parameters -- how in practice to OpenSearch consumers deal with custom parameters?
- CC filters entirely specified in
searchTerms
.
Implementation
- Implement best practices in CcHost
- Encourage search services that support OpenSearch and remember license info for searchable materials to include license annotations in OpenSearch result feeds, per existing extensions.
See Also
- http://www.opensearch.org
- http://en.wikipedia.org/wiki/OpenSearch
- CC Search -- CC's simple "frame" interface available at http://search.creativecommons.org, unrelated in terms of technology to OpenSearch
- Syndication -- license annotations in syndication formats