Re: [web-annotation] Support for search

@azaroth42 (in response to your 
[proposal](https://github.com/w3c/web-annotation/issues/48#issuecomment-164157710)).
 

I am not yet in position to say yay or nay to your original question, 
just musing here to, hopefully, add arguments to the issue for further
 discussions.

1. If we go with the IIIF Search API as a starting position, I believe
 that main (only) part we would take over is the equivalent of 
[section 3.2](http://search.iiif.io/api/search/0.9/#request). Indeed, 
I would expect the returned data should be exactly the same as the 
response in our protocol spec, i.e., what is described in the 
[annotation 
containers](https://w3c.github.io/web-annotation/protocol/wd/#annotation-containers),
 rather than what is in IIIF. Maybe the only thing that I would think 
about taking over, too, is the ``search:Hit`` object, so to say, i.e.,
 an additional information in the returned annotation that gives, 
essentially, the selector that lead to that particular response. Other
 than that, we should not have a different response to a query than 
what we already have for direct request. (We may have to add some 
additional parameters in the response header via `Link`, I am not 
sure.) 

2. Looking at [section 
3.2](http://search.iiif.io/api/search/0.9/#request) and, in 
particular, the table describing the query arguments, I would
        1. Add the ``role`` argument alongside the motivation (well, 
whatever the the name of that thing will be as an outcome of issue 
#112)
        2. I am not sure that the ``user`` and the ``box`` arguments 
have a role to play for us

*If* we adopt this, there are questions that we will have to answer, 
though. Some that come to my mind:

1. One aspect is not clear to me in IIIF. The spec suggests that the 
value of the ``q`` argument could be a regular expression (there is a 
``b*`` example somewhere down the line). Which would be fine, but this
 is not what the spec says:

        > A space separated list of search terms. The search terms may
 be either words (to search for within textual bodies) or URIs (to 
search identities of annotation body resources).

        What is exactly the situation in IIIF? (B.t.w., why space 
separated? Shouldn't it be comma separated for a URI?) What would be 
the useful thing for us, i.e., would we want regex or something else?
        
2. What happens if the annotation includes several bodies? Do we 
return an annotation with only the selected body, or do we return the 
full annotation? In some sense, is the original annotation the 
indivisible entity, or can a server produce a bona fide annotation by 
restricting it to the selected body?

3. Don't we need a similar query on the target rather than the body? 
I.e., instead of a `q` parameter, having something like `t` for 
targets, searching either to the target's URI or word in case a 
selector is used.

4. On a more general level, would that be *the* search facility for 
the annotation protocol? I think even if we decide to go ahead, it 
should be formulated as *one of the possible* search formulations, and
 that implementations are free to adopt other, more powerful 
facilities. While I agree with [your 
response](https://github.com/w3c/web-annotation/issues/48#issuecomment-139571573)
 to the comment of @akuckartz, we may want to use a more general 
framework, saying
        
        * implementations may define/use other search facilities 
(although it must implement what we define as the basis)
        * the return for all the search facilities should follow the 
[annotation 
containers](https://w3c.github.io/web-annotation/protocol/wd/#annotation-containers)
 part of the spec for their return. 


-- 
GitHub Notification of comment by iherman
Please view or discuss this issue at 
https://github.com/w3c/web-annotation/issues/48#issuecomment-164432287
 using your GitHub account

Received on Monday, 14 December 2015 13:10:37 UTC