Hi Tony -
> I thought that DAL was meant to spec the protocols for data access and so
> thought SkyNode came under that remit. This might also allow the development
> of common approaches to the data/image/spectra access protocols.
This is correct. DAL should include a basic catalog access service and we should have uniformity across all the DAL services, although they will each be specialized somewhat for the type of data accessed. In particular the query mechanisms should be similar.
> I saw SkyNode as the protocol, and ADQL as one of the input parameters.
> SkyNode specifies the methods and parameters that any data access service
> must provide. One of the input parameters to the query method is the query
> itself and ADQL is the format that that query is in.
I don't see SkyNode as being so fundamental that it specifies the methods and parameters for any DAL service. In any case, the advanced query mechanism (ADQL) should ultimately become an element of all DAL services, and since basic catalog access is little more than a query this is the logical place to develop and test this facility.
In my view SkyNode has thus far had little or no integration with DAL. We have been trying to get an initial advanced query capability up and running. It makes sense for VOQL to take the lead on developing this technology. This technology is getting to the point where we should look at what is needed for integration into DAL, and this is one of the goals for the May meeting. The following is from the most recent DAL roadmap:
Simple Catalog Access
Scope: Simple queries to individual catalogs (e.g., CS, SkyQuery). More complex catalog operations, e.g., query portals, distributed cross-matching, etc., are handled elsewhere within VO. Status: Current interface is Cone Search with no QL. Relevant work is currently going on within the ADQL WG; we need to determine how to recast portions of this as a DAL service. 2. Agree upon scope and plan for DAL catalog access service. 30-May-2004
> > about more sophisticated query capabilities in the DAL
> What was asking about were basic data access capabilities.
Ok, we are talking about the DAL catalog access service then.
> > services. In the meantime adding access to new classes of
> > astronomical data such as spectra and time series is more
> > productive. Nonetheless, you have a good point.
> > Perhaps we should expand the future topics session and
> > increase the emphasis on catalog access and query language
> > integration into the DAL services.
>
> I was posing the question. If image and spectra access are more important
> than data access, then fine. If not, we really ought to focus on getting the
> data access spec nailed down before the others. Again, if the decision of
> the two groups is that VOQL workgroup looks after the data access protocol
> while DAL looks after image and spectra access protocols that's also fine -
> as long as it is explicitly agreed and there's agreement on the common areas
> to ensure we get coherent protocols out of the two groups.
A note on terminology: usually in astronomy when we talk about "data" we mean any kind of observed or processed data. This includes "image data", "spectral data", "catalog data", "time series data" and so forth. The "data" in DAL means all these things. If anything is not "data" it is a catalog, since this is the product of analysis, but the term is loose enough to cover both areas.
I am not sure what the problem is though. We are making good progress in all these areas. I think it is best if ADQL develops the technology such as ADQL which is needed for catalog access, and this seems to be coming along fine. SkyNode is being developed currently not as a DAL service but as part of a larger scheme for distributed and large scale queries, which I agree could potentially become a problem. By the May meeting we should be talking about a DAL catalog access service based on this technology, and ADQL integration into DAL services, but it is reasonable to let the VOQL WG do some initial technology development first.
> > DAL, there is no clear distinction between tabular and
> > gridded data, so it would be a mistake to try to split the two.
>
> What is tabular and what is gridded data and what is the (non-)difference?
Tabular data includes things like spectra, time series, event and visibility data, and of course source catalogs (at least, all are tabular in nature). Gridded data means things with a pixel grid like an image or spectral data cube.
> > Hence I think it makes sense to have a separate group develop
> > the query technology.
>
> No problem with that. But the interface is a DAL issue - possibly delegated
> to the VOQL group if that is the decision.
I agree that a basic catalog access interface should be part of DAL. But I think the scope of VOQL is broader, with more ambitious goals, and it makes sense for VOQL to do the initial technology development in this area. In the case of SkyNode it may be best to get something working first, and see what seems to be a natural solution in this area, before tackling the problem of integration with other DAL services. Changes can be expected to be required: probably we will be talking about a new version of the catalog access service as well as new versions of the DAL services, in order to achieve integration. We have this problem all over VO, not just in integrating query language facilities.