Meetings: InterOpMay2011Registry Requirements and Use Cases for New Registry Search InterfaceThis page aims to capture requirements and use cases for a new (post-RI v1.0) registry search interface. The RI v1.0 spec provides two interfaces for searching: one is a required ADQL-based interface and the other is an optional XQuery-based query. Both use SOAP. Since a searchable registry is only required to support the ADQL interface, this is the one that applications would prefer to be interoperable across registries. These interfaces, and particularly the ADQL interface, have following disadvantages:
Use CasesConsider the following as potentially useful queries and ways to express queries. not all of which may be included explicitly in a standard interface. In addition to adding more use cases, feel free to add comments to those that already appear that would indicate their relative importance or role for an application. For the purposes of discussion, annotate with your name (or linked initials). -- Ray Plante (RP)Interface clientsClients that would interact with a programmable web search interface:
Sample Queries
| ||||||||
Added: | ||||||||
> > |
| |||||||
Query InteractionsThis section looks at possible service interaction patterns.Single Resource resolution
| ||||||||
Added: | ||||||||
> > | I am not so sure if GetCapabilities and GetTables are important operations on the registry since VOSI now requires the respective endpoints on the services themselves. But a quick way to get an access URL from an ivoa id would certainly be most welcome. We'd need to specify the answer for ids that have no access URLs, though. As to the retrieval of the whole record, I think that is sufficiently covered by OAI-PMH. --MD One issue that I cannot dismiss by handwaving towards ADQL is the "keyword search" thing. In a mail to the registry mailing list dated 2011-05-24T10:40:38, PaulHarrison notes that the current state of wildly differing responses of different registries to identical keywords is a pain. While I would stipulate that quite a few of the differences are due to registries in fact holding significantly differing data, I agree the concept of "keyword search" needs some clarification. This is particularly true since offering "google-style" queries is highly desirable when everyone feels they know how to use google. Now, ADQL has no built-in provisions for "IR-like" queries (where IR here means Information Retrieval). One way to work around this could be a user-defined function registry interfaces should provide, maybe along the lines of Postgres' Text Search functions and operators -- say, haswords("quasar recent", description). --MD | |||||||
Search QueriesSearch queries provide return a list of records that match a set of input constraints. We note that a resource record can, in general, have zero or more capabilities associated with it, and each capability can have multiple interfaces (e.g. supporting different versions of a capability), each with its primary own accessURL. Thus, the result records return from search queries could represent ...
Possible output forms
| ||||||||
Added: | ||||||||
> > | If we use TAP as an access protocol, this question largely becomes moot. People will get VOTables by default, but if the system supports other formats, they can get data in those, too. The only exception is the list of VOR records, since they would probably not be accessible through TAP. These, however, are already covered by OAI-PMH, which the registry needs to speak anyway. I think OAI-PMH has enough expressivity for those applications that actually want to deal with VOR records.. --MD | |||||||
Ways to constrain search results
| ||||||||
Added: | ||||||||
> > | I'm all for straight ADQL as the default query language in RI, but then I'm biased because that would be very easy for me. Still, most astronomers wanting to use the VO will -- I hope! -- learn ADQL, and not supporting it on our registries will not look good. This means we'll need to store the essential aspects of VOResource in relational tables. So, what about extensibility? Ray, do you have examples of those specialized capabilities? The example I can think of, data model support in TAP services, could be covered using a table containing tuples of ivo id, keyword, and value -- maybe that would be sufficient for most of these? --MD | |||||||
RequirementsHere we list any functional and technical requirements (some deriving from the above use cases).
| ||||||||
Added: | ||||||||
> > |
| |||||||
Implementation ConsiderationsHere we collect considerations for implementations that do not necessarily derive from requirements (but may feed into them).XML vs. Relational DB backendsThe current RI v1.0 search interface reflects an attempt to provide a search interface that could be implemented against either an XML database backend or a relational one. Can this be achieved with a new, RESTful design? Can at least part of the interface be database agnostic? Is it worth trying? | ||||||||
Added: | ||||||||
> > | PaulHarrison on the mailing list (mail dated 2011-05-24T10:40:38) argued that if we move RI towards TAP/ADQL then a "full relational registry data model should be attempted" and in consequence "we probably should stop using XML schema to describe the registry model". While I'd always advocate avoiding XML schema wherever possible, I disagree here on dropping current VOResource practice. We are part of the bibliographic community, and OAI-PMH is XML-based. In my view, it is the "primary source" of our registry information (which essentially is just a collection of bibliographic records). I'd much rather see a map of "as many" of VOResource features as "proportional" (to the purposes defined by the use cases) to some relational model. --MD | |||||||
TAP InterfaceA TAP interface that supports a "Registry Data Model" has an advantage to developers (in particular, scripters) because it is potentially a query interface they already know.
<--
|