W3C home > Mailing lists > Public > public-annotation@w3.org > January 2016

Re: [web-annotation] Support for search

From: gsergiu via GitHub <sysbot+gh@w3.org>
Date: Mon, 04 Jan 2016 17:25:22 +0000
To: public-annotation@w3.org
Message-ID: <issue_comment.created-168742589-1451928320-sysbot+gh@w3.org>
Some feedback from my experience with (metadata) search engines:

1. The search API, typically return a preview (i.e. a view in the 
model-view-controller design) of the annotations and not the full 
objects. Some solutions allow user to select which properties to be 
returned (e.g. SQL fashion), others use predefined profiles (e.g. a 
minimal/standard/full). The number of total results must be present in
 each request, and also the "pagination" information (i.e. in solr 
uses start and rows parameters). 

2.  I think that all properties of the annotations must be 
searchable/indexed ... and search according to their data types (e.g. 
creation data, creator, tag labels, even the generator)   

3. regarding the definition of the "q" parameter. This is actually a 
string serialization of a query, which might be a simple text query or
 it might be a kind of metadata-based query (in which case the query 
must be often URL-Encoded) ... see also lucene query syntax: 

4. about the concern about multiple bodies in the search response, I 
think this can be solved through usage of search profiles as mentioned
 in 1.

5. About the search in target, yes .. it is a must to implement the 
search by target. Given the 3. above, the q parameter is the 
serialization of the full query, while target is only one property of 
the query. In json we could have a query like this:
"q" : {
  "creator" : "myself",
  "target" : "http://mywebsite.com/myobject"
The submition of queries as json format with POST method, would be 
quite good for developers. Still for many cases GET is preferred .. 
therefore ... the ugly string serializations like in the amazon 
example in previous post ....

6. I think that the specification of the search API is bound to API 
technology. If the API is REST + JSON-LD, the input should be 
json(-ld). If the API is RDF/XML based, this might use xquery or 
something like that (which can be translated internally in a sparql 
query if needed). The query is the input of the search, as the 
annotation is the input of the create annotation method. I think that 
the two APIs should be consistent. 



GitHub Notification of comment by gsergiu
Please view or discuss this issue at 
 using your GitHub account
Received on Monday, 4 January 2016 17:25:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:43 UTC