Re: SRU/CQL requirements

Thanks Ray,

Is my understanding correct that CQL is some sort of a framework? Framework in the sense that we have to define which indexes are usable in our environment and how they translate onto the model? This is different then making a search based on, say, SPARQL (which would also be the basis of an LDP Search I presume) which would reflect the exact RDF structure, and namespace, etc. (To make it clear, I would prefer not to go down the SPARQL route, or making it an implementation dependent option rather than include it in our recs.)

Another question/comment is on the '=' operator like 'body = cat' in your example. Is this defined to be an exact match, or a submatch, or something similar? I would expect that some sort of a (possibly simplified) regular expression match may be more useful for our purposes. I do not know whether CQL has this facility.

Ivan

> On 30 Apr 2015, at 15:49 , Denenberg, Ray <rden@loc.gov> wrote:
> 
> This is in response to the action item assigned to me to “Provide summary of sru level 1” .
> 
> To clarify: It is actually CQL that needs to be summarized.   (SRU is a  protocol and CQL is its companion query language. )
> 
> First, some terminology and brief background.
> 
> Consider the query:
> 
>                 motivation = tagging  AND  annotatedAt   >  20150401
> 
> (which says “find annotations with  Motivation  oa:tagging  created later than  April 1, 2015”)
> 
> Each of:
> ·         motivation = tagging
> ·          annotateAt   >  20150401
> is, In CQL terminology. a  search clause.
> 
> A search clause consists of an index, relation, and search term (“term” for short).
> Thus:
> ·         ‘motivation’  and ‘annotatedAt’  are indexes.
> ·          ‘=’ and  ‘>’  are relations.
> ·         ‘tagging’ and ‘20150401’ are search terms.
> 
> A search clause may consist of the term only. The index and relation may be omitted in which case the system defaults for these apply (and so the search clause is still considered to be index-relation-term even if only the term is supplied). So for example the following is a legitimate CQL query:
> 
>                                 cat
> 
> which expands to
> 
> [default index]   [default relation]  cat
> 
> The system default relation is usually ‘=’;  furthermore, the system may define ‘=’ to mean whatever it wants. So the query ‘title=cat’ on most systems means “find documents with ‘cat’ in the title”  as opposed to documents whose title is exactly ‘cat’.  There is also the relation ‘==’ to mean “exact”.
> 
> An SRU annotation database could define “body” to be the default index.
> 
> The query
> 
>                 body = cat
> 
> Would say “find annotations with ‘cat’ in the body.”
> 
>   And that query  could be abbreviated as:
> 
>                          cat
> 
> 
> So, let’s get down to requirements:
> 
> Formally speaking, conformance to CQL level 1  requires support for at least one of the following:
> (a)    queries where search terms are combined with booleans, e.g. "cat AND dog"
> (b)   full search clauses; i.e. where index and relation are explicitly supplied rather than defaulted;
> e.g. “motivation = tagging”
> 
> This means that if you support Boolean operators then you don’t have to support full search clauses; and conversely, you don’t have to support Booleans but if you don’t then you have to support full search clauses.
> 
> Note that I said “formally” above, because I think this is over specified  (blame me for that).  I suggest for our purposes that we require support for:
> ·         Boolean operators (AND, OR, NOT)
> ·         Full search clauses
> ·         Term-only search clauses
> 
> Let’s take this a step at a time.  If after looking at this, we want to pursue it further, I will provide more detailed background, including additional background on the SRU protocol, and begin to draft a proposed profile of SRU/CQL for annotations.
> 
> Ray


----
Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704

Received on Friday, 1 May 2015 08:08:14 UTC