new RI document

Wed Jun 14 09:49:52 PDT 2006

Hi Kevin.
I've some questions with KeywordSearch (with my client-application- 
developer hat on).

Q: In the specification of keyword search, does it define which  
fields /sections of the registry records are to be searched?

I think this might be desirable - or at least a recommendation on  
which parts of the registry records should be searched. Otherwise, a  
client may get different results for the same query when connecting  
to different registries. Which is odd, considering that most large  
registries will be harvesting each other.

Q: If you are going this route, maybe the order in which results are  
returned should be defined too - or at least recommended. (e.g. I'd  
expect matches in 'title' to occur before matches in some other field  
- such as 'description').

Q: is keyword search case sensitive? does keyword search only match  
whole words, or word fragments. Or something more useful - like  
Soundex (http://en.wikipedia.org/wiki/Soundex) - or even searching  
for object aliases - as provided by simbad??

The reason I'm asking this is that, as an application developer, I'd  
like uniform behaviour no matter what registry implementation my  
application is connected to - otherwise it may well bamboozle users.

If keyword search on the registry interface is so loosely specified  
(as, IIRC, it is now) that the behaviour can't be predicted, then  
clients may well  be better off constructing their own adql/xquery  
expressions that implement 'keyword search' for their users, but  
under their own, predictable, terms.

Actually, this sounds like the most sensible approach anyhow - as a  
client app mostly working with, say, coverage, is going to consider  
different fields to have higher importance than a client app  
concerned with, say, curation details.

In which case, would be best route be to simplify the registry spec &  
implementations by removing keyword search altogether? Or replacing  
it with a 'full text literal match search'

cheers
noel.

On 14 Jun 2006, at 17:16, KevinBenson wrote:

> After a telecon today here are some of the decisions made, feel  
> free to comment if you don't agree or need more discussion.
>
> 1.)  Search and KeywordSearch methods will only return active and  
> inactive resources.
> 2.)  KeywordSearch will have an exception to use quotation marks to  
> define exact phrases.
> 3.)  A new interface method will be created (possibly GetIdentity)  
> which returns the Registries vg:Registry resource just like the  
> VOSI getRegistration.  VOSI will be taken out of the RI spec.
> 4.)  GetResource will reference vr:IdentifierURI instead of xs:string.
>
> cheers,
> Kevin
>
> Aurelien Stebe wrote:
>> Hi Kevin,
>>
>> I reviewed the doc and here are a few comments :
>>
>> - Should we write in the RI that the "Search" and "KeywordSearch"  
>> methods must return only "active" (and maybe "inactive")  
>> resources ? I don't think "deleted" resources should be returned  
>> in a search, they should be when using the harvest interface. Of  
>> course, "GetResource" would return the resource whatever the  
>> status is.
>>
>> - Two small questions to make the "from" and "to" search  
>> parameters clearer : are Registries allowed to return less  
>> resources than asked ? If the user wants "from=1" and "to=1000",  
>> may I return only 500 entries because that's my Registry limit ?  
>> and is the "to" parameter inclusive or not (really a detail, but  
>> well ...).
>>
>> - Should we allow for Strings search in KeywordSearch ? I mean  
>> allow the user to search for "black hole" without having it  
>> separated into 2 words. We could write that expressions enclosed  
>> in double quotes must be treated as one unique word.
>>
>> - Two small typos : in the list of metadata to search in 2.3 the  
>> last one is missing "content" -> "content/type". Also, namespaces  
>> prefixes should be deleted to be consistent. In 2.4 : "IVOA  
>> searchable registries can optionally implement the  
>> GetResource ....". Isn't it a compulsory method ?
>>
>> - In 2.6 : I don't think the VOSI should be mentioned here since  
>> it is not a Rec yet. It puts a dependence on the RI for passing to  
>> Rec level. If a "getRegistration" is needed in the future it might  
>> come along with the VOSI, or we might add it to the Search  
>> interface of RI v1.1  . If it is needed now, it should be in the  
>> Search interface of the RI v1.0  .
>>
>> - In 3.1.1 : "ListRecords : [....] ,as well as the resources of  
>> the Registry type. [....]" . I guess this is from previous  
>> versions of the RI. The "ListRecords" used with "set=ivo_managed"  
>> should return managed entries and those only. Also, it should be  
>> written that if no "set" is specified, ALL records will be  
>> returned (or is it obvious ?)
>>
>> Other than that, I think it is pretty much ready for PR. The  
>> Registry extension schema will need to be attached, as we decided  
>> each specification is responsible for providing the schema  
>> extension. I didn't read the WSDLs, but I guess we will only need  
>> to check those later, to make sure they reflect the doc.
>>
>> Cheers,
>> Aurelien
>>
>>
>> KevinBenson wrote:
>>> There is a new RI document (0.8.2) located at IVOA (see links  
>>> below).  There are still a few areas that need to be cleared up,  
>>> but would like to start getting comments from the group.
>>> Also note my last e-mail subject "Two questions about xsi:type"  
>>> would be good to have some replies/comments on that e-mail  
>>> especially question 2.
>>> A final note the RI currently says ADQL 1.0, I will check on the  
>>> version of the ADQL-Core schema to see how it fits into the RI  
>>> document.
>>>
>>> Thank you in advance for any comments and information about the  
>>> RI document,
>>> Kevin
>>>
>>> Word doc - http://www.ivoa.net/internal/IVOA/RegistryInterface/ 
>>> RegistryInterface-v0.8.2.doc
>>> PDF doc - http://www.ivoa.net/internal/IVOA/RegistryInterface/ 
>>> RegistryInterface-v0.8.2.pdf
>>> Main RI site - http://www.ivoa.net/twiki/bin/view/IVOA/ 
>>> RegistryInterface
>

---
http://wiki.astrogrid.org/bin/view/Main/NoelWinstanley
Senior Java Developer, AstroGrid Project
Jodrell Bank Observatory, University of Manchester