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. | ||||||||
Changed: | ||||||||
< < | There's now a page to discuss Registry Interfaces version 2 at RI2Discussion. | |||||||
> > | There's now a page to discuss Registry Interfaces version 2 at RI2Discussion. Following the Sao Paulo IVOA Interop, the RWG agreed to pursue a new REstFul approach based on 2 protocol directions:
| |||||||
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
Query InteractionsThis section looks at possible service interaction patterns.Single Resource resolution
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
Ways to constrain search results
RequirementsHere we list any functional and technical requirements (some deriving from the above use cases).
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? 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 I have put together a page with some modelling of a Relational RegistryDM --PHTAP 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.
| ||||||||
Changed: | ||||||||
< < | ||||||||
> > |
| ||||||||
Changed: | ||||||||
< < | Jumps: IvoaResReg :: registry mail archive :: RegistryMetadata :: VOResourceV10 | |||||||
> > | Jumps: IvoaResReg :: registry mail archive :: RegistryMetadata :: VOResourceV10 Meetings: InterOpMay2011Registry | |||||||
Deleted: | ||||||||
< < | 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. | ||||||||
Changed: | ||||||||
< < | 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:
| |||||||
> > | There's now a page to discuss Registry Interfaces version 2 at RI2Discussion. | |||||||
Deleted: | ||||||||
< < |
| |||||||
Changed: | ||||||||
< < | This effort is motivated to address these problems by providing a searchable interface that is simpler and scriptable. | |||||||
> > | 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: | |||||||
Added: | ||||||||
> > |
| |||||||
Use Cases | ||||||||
Changed: | ||||||||
< < | Consider 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). | |||||||
> > | Consider 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: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Sample Queries | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | ||||||||
I would like to query the registry at a little more fine grained level: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | ||||||||
This could be better done having a better description of services: - Having an "object type" keyword with values "galaxy, star, brown dwarf, etc" | ||||||||
Changed: | ||||||||
< < | - Having a "data type" keyword with values like "spectrum, time series, datacube, isochrone, | |||||||
> > | - Having a "data type" keyword with values like "spectrum, time series, datacube, isochrone, distance, photometry, etc". | |||||||
Deleted: | ||||||||
< < | distance, photometry, etc". | |||||||
Changed: | ||||||||
< < | These keyword should be multivalued (a service giving distances and photometry for stars and | |||||||
> > | These keyword should be multivalued (a service giving distances and photometry for stars and galaxies). And, even though one could imagine them as a predefined set of values, I think it's more practical to leave them as free text. I imagine that the registry web form could contain a select field with all the values previously used by other services so that the registrant can choose among them and thus try to avoid too many different words with almost the same meaning. | |||||||
Deleted: | ||||||||
< < | galaxies). And, even though one could imagine them as a predefined set of values, I think it's more practical to leave them as free text. I imagine that the registry web form could contain a select field with all the values previously used by other services so that the registrant can choose among them and thus try to avoid too many different words with almost the same meaning. | |||||||
Changed: | ||||||||
< < | - Having a "data origin" keyword to specify if the service provides observational or | |||||||
> > | - Having a "data origin" keyword to specify if the service provides observational or theoretical data (this could be done now using "content type=simulation" for theoretical data, but it is quite confusing, because the other options don't need to correspond to observational data either). | |||||||
Deleted: | ||||||||
< < | theoretical data (this could be done now using "content type=simulation" for theoretical data, but it is quite confusing, because the other options don't need to correspond to observational data either). | |||||||
If the user has the option to choose before querying the registry for services, then the query itself would be more powerful, and so the following use cases would have sense: | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Deleted: | ||||||||
< < | ||||||||
--CRB
Query Interactions | ||||||||
Changed: | ||||||||
< < | This section looks at possible service interaction patterns. | |||||||
> > | This section looks at possible service interaction patterns. | |||||||
Changed: | ||||||||
< < | Single Resource resolution | |||||||
> > | Single Resource resolution | |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
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 | |||||||
Changed: | ||||||||
< < | I am not so sure if GetCapabilities and GetTables are important operations | |||||||
> > | 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 | |||||||
Deleted: | ||||||||
< < | 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 | |||||||
Deleted: | ||||||||
< < | 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 Queries | ||||||||
Changed: | ||||||||
< < | Search queries provide return a list of records that match a set of input constraints. | |||||||
> > | Search queries provide return a list of records that match a set of input constraints. | |||||||
Changed: | ||||||||
< < | 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 ...
| |||||||
> > | 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 ...
| |||||||
Added: | ||||||||
> > | In principle, these could come back in a variety of formats, including table formats. Desktop applications, portal apps, and workflow builders will usually want to get a few pieces of information (most notably, a service's accessURL; see opening motivation above). It would be both easier for these clients and more efficient if the client could specify exactly what information they want back. | |||||||
Deleted: | ||||||||
< < | In principle, these could come back in a variety of formats, including table formats. Desktop applications, portal apps, and workflow builders will usually want to get a few pieces of information (most notably, a service's accessURL; see opening motivation above). It would be both easier for these clients and more efficient if the client could specify exactly what information they want back. | |||||||
Possible output forms | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Added: | ||||||||
> > | Questions:
| |||||||
Changed: | ||||||||
< < | Questions: | |||||||
> > | I don't think that multiple output formats are very useful. The clients will normally be software of some sort rather than a human directly talking to the registry service (no?), and such clients can easily transform from a single format (presumably VOTable) to whatever makes sense for the user. -- MT | |||||||
Deleted: | ||||||||
< < |
| |||||||
Deleted: | ||||||||
< < | 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 I don't think that multiple output formats are very useful. The clients will normally be software of some sort rather than a human directly talking to the registry service (no?), and such clients can easily transform from a single format (presumably VOTable) to whatever makes sense for the user. -- MT | |||||||
Ways to constrain search results | ||||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
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 | |||||||
Deleted: | ||||||||
< < | 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 | |||||||
Requirements | ||||||||
Changed: | ||||||||
< < | Here we list any functional and technical requirements (some deriving from the above use cases). | |||||||
> > | Here we list any functional and technical requirements (some deriving from the above use cases). | |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Changed: | ||||||||
< < |
| |||||||
> > | | |||||||
Added: | ||||||||
> > |
| |||||||
Implementation ConsiderationsHere we collect considerations for implementations that do not necessarily derive from requirements (but may feed into them).XML vs. Relational DB backends | ||||||||
Changed: | ||||||||
< < | The 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? | |||||||
> > | The 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? | |||||||
Changed: | ||||||||
< < | PaulHarrison on the mailing list (mail dated 2011-05-24T10:40:38) argued that | |||||||
> > | 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 | |||||||
Deleted: | ||||||||
< < | 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 | |||||||
I have put together a page with some modelling of a Relational RegistryDM --PH
TAP Interface | ||||||||
Changed: | ||||||||
< < | A 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. | |||||||
> > | A 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. | |||||||
Changed: | ||||||||
< < |
| |||||||
> > |
| |||||||
Changed: | ||||||||
< < |
| |||||||
> > | ||||||||
Deleted: | ||||||||
< < |
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
Query InteractionsThis section looks at possible service interaction patterns.Single Resource resolution
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
Ways to constrain search results
RequirementsHere we list any functional and technical requirements (some deriving from the above use cases).
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? 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 I have put together a page with some modelling of a Relational RegistryDM --PHTAP 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.
|
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
Query InteractionsThis section looks at possible service interaction patterns.Single Resource resolution
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
| ||||||||
Changed: | ||||||||
< < |
| |||||||
> > | ||||||||
| ||||||||
Added: | ||||||||
> > | I don't think that multiple output formats are very useful. The clients will normally be software of some sort rather than a human directly talking to the registry service (no?), and such clients can easily transform from a single format (presumably VOTable) to whatever makes sense for the user. -- MT | |||||||
Ways to constrain search results
RequirementsHere we list any functional and technical requirements (some deriving from the above use cases).
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? 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 I have put together a page with some modelling of a Relational RegistryDM --PHTAP 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.
<--
|
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: | ||||||||
> > | ||||||||
- Having a "data type" keyword with values like "spectrum, time series, datacube, isochrone, distance, photometry, etc". These keyword should be multivalued (a service giving distances and photometry for stars and galaxies). And, even though one could imagine them as a predefined set of values, I think it's more practical to leave them as free text. I imagine that the registry web form could contain a select field with all the values previously used by other services so that the registrant can choose among them and thus try to avoid too many different words with almost the same meaning. - Having a "data origin" keyword to specify if the service provides observational or theoretical data (this could be done now using "content type=simulation" for theoretical data, but it is quite confusing, because the other options don't need to correspond to | ||||||||
Changed: | ||||||||
< < | observational data either). --CRB | |||||||
> > | observational data either). | |||||||
Added: | ||||||||
> > |
If the user has the option to choose before querying the registry for services, then the query itself would be more powerful, and so the following use cases would have sense:
| |||||||
Query InteractionsThis section looks at possible service interaction patterns.Single Resource resolution
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
Ways to constrain search results
RequirementsHere we list any functional and technical requirements (some deriving from the above use cases).
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? 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 I have put together a page with some modelling of a Relational RegistryDM --PHTAP 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.
<--
|
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: | ||||||||
> > |
I would like to query the registry at a little more fine grained level:
| |||||||
Query InteractionsThis section looks at possible service interaction patterns.Single Resource resolution
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
Ways to constrain search results
RequirementsHere we list any functional and technical requirements (some deriving from the above use cases).
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? 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 I have put together a page with some modelling of a Relational RegistryDM --PHTAP 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.
<--
|
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
Query InteractionsThis section looks at possible service interaction patterns.Single Resource resolution
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
Ways to constrain search results
RequirementsHere we list any functional and technical requirements (some deriving from the above use cases).
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? 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 | ||||||||
Added: | ||||||||
> > | I have put together a page with some modelling of a Relational RegistryDM --PH | |||||||
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.
<--
|
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.
<--
|
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:
| ||||||||
Added: | ||||||||
> > | ||||||||
Use Cases | ||||||||
Changed: | ||||||||
< < | Here we list some sample queries we would like to be able to support. | |||||||
> > | Consider 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). | |||||||
Added: | ||||||||
> > | -- Ray Plante (RP) | |||||||
Added: | ||||||||
> > | Interface clients | |||||||
Added: | ||||||||
> > | Clients that would interact with a programmable web search interface:
Sample Queries
Query InteractionsThis section looks at possible service interaction patterns.Single Resource resolution
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
Ways to constrain search results
| |||||||
RequirementsHere we list any functional and technical requirements (some deriving from the above use cases).
| ||||||||
Changed: | ||||||||
< < | Implementation Recommendations | |||||||
> > | Implementation Considerations | |||||||
Changed: | ||||||||
< < | Here we collect ideas for implementations that do not necessarily derive from requirements. | |||||||
> > | Here we collect considerations for implementations that do not necessarily derive from requirements (but may feed into them). | |||||||
Added: | ||||||||
> > | 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?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.
| |||||||
<--
|
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 Cases | ||||||||
Added: | ||||||||
> > | Here we list some sample queries we would like to be able to support. | |||||||
Deleted: | ||||||||
< < | Requirements | |||||||
Changed: | ||||||||
< < | Implementation Recommendations | |||||||
> > | Requirements | |||||||
Added: | ||||||||
> > | Here we list any functional and technical requirements (some deriving from the above use cases). | |||||||
Added: | ||||||||
> > |
| |||||||
Added: | ||||||||
> > | Implementation Recommendations | |||||||
Changed: | ||||||||
< < | ||||||||
> > | Here we collect ideas for implementations that do not necessarily derive from requirements. | |||||||
<--
|
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 CasesRequirementsImplementation Recommendations<--
|