Dear Roy et al,
> As Maria points out, the work done so far on source catalogs assumes a
> RDBMS table model. There is the Skynode protocol that allows an
> arbitrary table to be exposed through web services that allow
> discovery of the list of tables and table metadata, and to send
> queries (ADQL, based on SQL) to the database. The model is extended in
> the case of tables that have positional information, where crossmatch
> and regions are introduced.
> Your Catalog model is thus a further extension of Skynode. It seems
> that you are adding
> (1) Curation, content, and coverage information for the catalog, and
> (2) Specific semantic meanings for the columns of the table
>
> Is this a correct interpretation?
the IVOA (Source) Catalogue Data Model is one of the family of data models being created by the IVOA Data Model group. In this case, dealing with catalogues and sources. (I just happen to be the coordinator nominated by Jonathan to deal with this one)
In this sense, it is not an "extension" of the SkyNode, but a precise description of certain data.
It could also be interpreted as a "view" of source catalogued data; and therefore, in the specific case of dealing with SkyNodes, it could be used as a view on top of data accessible through a SkyNode, using ADQL.
In our proposal we access Basic SkyNodes that expose their data through SourceDM "views". Quoting the SkyNode specification:
"[...]Basic SkyNode here is the minimum IVOA SkyNode interface - this is useful in itself as it allows one to send queries to a system using ADQL [...]"
What we have done, thus, is to add -as you say- specific data model meaning to data accessible to Basic SkyNodes through ADQL.
This goes in line with other paragraph on the specification of the SkyNode:
"[...]Hence, ADQL would be passed from the SkyQuery Portal to the SkyNodes or it may come directly from a client[...]".
our proposal for client-side crossmatch just uses ADQL to access Basic SkyNode which expose a Source-DM view, therefore following the specifications with the added value of the a-priori knowledge that the Source DM gives.
We've helped our CDS colleagues to build these Basic SkyNodes with Source DM views to try and demonstrate the usability of the IVOA Source DM and eventually be able to fine-tune it and have it endorsed by the whole community.
We would like to propose our JHU colleagues to implement these Source DM "views" on their SkyNodes that we could use together with the CDS ones, our own ones, etc., therefore having a bigger and better test bed for the relevance or otherwise of the Source DM, and be able to polish it.
> (a) In the case of (1), can you tell me if you have used the Resource
> Metadata model/schema that the Registry group has built?
yes, the information on Curation in the Source DM that I sent is exactly copied from there.
> can I copy the curation-content-coverage information verbatim and use
> it in your catalog model. (If not, why not?)
you should even be able to point to it, although I understand that how to do these things is still under discussion. In case this is not possible, and as the idea was to replicate the Curation contents from the Registry (if it is already there, why to reinvent something that already exists), then yes: you should be able to copy and use it in the catalogue model.
> (b) Your section 3.4 (page 12) has specific definitions of words that
> describe sources. For example "redshift" and "radialVelocity". Can I
> assume that these can be used as the utype attribute of VOTable? The
> representation of a table might look like this:
> <FIELD name=z utype=dmc:redshift>
> Is that correct?
>
it is correct.
> (c) Your page 5 shows a query "in pseudo-code". How close is this
> pseudo code to real ADQL? It looks like you are using your utypes in
> place of column names. In the example above, how do I ask for high
> redshift sources, do I say "select * where z>4" or do I say "select *
> where dmc:redshift>4"?
>
you would rather use the "dmc:redshift" to identify the model, although this is all dressed up with proper ADQL and pointers to the xsd that identifies the model, etc.
> (d) To what extent do your source attributes match up with the UCD
> list? In other words, a great deal of effort has already been used in
> labeling catalog column names with UCDs (Vizier, SDSS, HEASARC, etc
> etc). I hope that there can be a direct, semantically-equivalent
> translation to your source attributes, otherwise I do not understand
> how you expect the Catalog model to gain implementation.
all the entries in the Source DM (as any other Data Model inside the IVOA DM group) will point to the relevant UCD. The document does not state it, but it will. As I said, that document is a very preliminary draft, only intended to write in paper something that would allow us to start fruitful discussions on the model.
You can see this type of coexistence of Data Model and UCDs in, for instance, the SED Data Model document at http://hea-www.harvard.edu/~jcm/vo/docs/spec.html (this one already well written).
> (e) For the source identifier, is your format the same as what the
> ADQL group has carefully defined?
>
I'm not sure what you mean with this one. The Source ID is intended to
be a name (normally numbers and characters) for the source which depends
on each catalogue. Some sources will eventually end up with an IAU
official id. Therefore we agreed to allow for at least an ID (arbitrary
and catalogue-dependent) plus the official IAU one, plus possibly SIMBAD
ones. Other options would be welcome.
I hope this bunch of answers clarifies some issues. The intention of this collaboration with CDS, and hopefully with JHU in a near future, was to enhance the usability of the Basic SkyNode paradigm, which is -in our view- the right approach to creating servers that understand ADQL.
Thank you and Feliz Anio nuevo (this absence of enies!..... ;-)
Cheers,
P.
>
On Fri, 2005-12-23 at 09:15 -0800, Roy Williams wrote:
>
>
> ______________________________________________________________________
>
> Pedro
>
> As Maria points out, the work done so far on source catalogs assumes a
> RDBMS table model. There is the Skynode protocol that allows an
> arbitrary table to be exposed through web services that allow
> discovery of the list of tables and table metadata, and to send
> queries (ADQL, based on SQL) to the database. The model is extended in
> the case of tables that have positional information, where crossmatch
> and regions are introduced.
>
> Your Catalog model is thus a further extension of Skynode. It seems
> that you are adding
> (1) Curation, content, and coverage information for the catalog, and
> (2) Specific semantic meanings for the columns of the table
>
> Is this a correct interpretation?
>
> (a) In the case of (1), can you tell me if you have used the Resource
> Metadata model/schema that the Registry group has built? If some large
> catalog is published to the Registry as a Data Collection, can I copy
> the curation-content-coverage information verbatim and use it in your
> catalog model. (If not, why not?)
>
> (b) Your section 3.4 (page 12) has specific definitions of words that
> describe sources. For example "redshift" and "radialVelocity". Can I
> assume that these can be used as the utype attribute of VOTable? The
> representation of a table might look like this:
> <FIELD name=z utype=dmc:redshift>
> Is that correct?
>
> (c) Your page 5 shows a query "in pseudo-code". How close is this
> pseudo code to real ADQL? It looks like you are using your utypes in
> place of column names. In the example above, how do I ask for high
> redshift sources, do I say "select * where z>4" or do I say "select *
> where dmc:redshift>4"?
>
> (d) To what extent do your source attributes match up with the UCD
> list? In other words, a great deal of effort has already been used in
> labeling catalog column names with UCDs (Vizier, SDSS, HEASARC, etc
> etc). I hope that there can be a direct, semantically-equivalent
> translation to your source attributes, otherwise I do not understand
> how you expect the Catalog model to gain implementation.
>
> (e) For the source identifier, is your format the same as what the
> ADQL group has carefully defined?
>
> Thank you and Feliz Navidad
> Roy
>
> California Institute of Technology
> 626 395 3670
-- Pedro Osuna Alcalaya ESA Science Archives System Engineer Science Archive Team European Space Astronomy Centre (ESAC/ESA) e-mail: Pedro.Osuna-at-esa.int Tel + 34 91 8131314 --------------------------------- European Space Astronomy Centre European Space Agency P.O. Box 50727 E-28080 Villafranca del Castillo MADRID - SPAINReceived on 2005-12-28Z18:06:23