Hi Pedro -
"Cast in stone" was a poor choice of words, and of course is not true, although I suspect everyone will understand the need to finalize SSAP and move it to PR - which will establish the pattern for the second generation DAL interfaces, as I have said many times in the interop sessions. This has been the main point of SSAP, not merely providing access to 1-D spectra.
With all the action now on SSAP, TAP, and SIAV2 planning, plus Registry V2, UWS, etc., it is a good time to consider matters such as getCapabilities and stageData. Lets just do it.
My apologies about writing stuff which is hard to follow; I agree, an abstract analysis is hard enough as it is, even without language problems. Perhaps we can work from some simple examples instead, as suggested in the email I just sent, and make more rapid progress. The encouraging thing, despite the apparent chaos, is that we are now getting into what I think are the critical issues where agreement is required.
On Wed, 25 Apr 2007, Pedro Osuna wrote:
> Hi Doug,
>
> thanks very much for the update.
>
> It is precisely what the getCapabilities functionalities are going to be
> what worries me, not when it was first mentioned, and the same thing for
> stageData.
>
> English not being my mother tongue I might sound rude when saying this,
> but honestly reading your mail I get lost in your reasoning, as it seems
> to be mixing when a thing was first mentioned with whether the important
> details are being discussed and with whom, and finally I have the
> sensation to not have understood what you want to say. I would beg you
> to consider that many of us in the IVOA are not using our own languages
> to express our ideas or questions, neither are we reading in our own
> language, so it would be helpful if you simplify your reasoning lines.
>
> I am only asking for an open discussion on important things like
> getCapabilities and stageData which are important for many services.
> If you bring it "cast on stone" to Beijing after having discussed it
> with only one or two persons, we risk finding severe problems in their
> conception, and we might finally end up failing to satisfy the
> community's needs.
>
> P.
>
>
>
>
>
>
>
> On Wed, 2007-04-25 at 07:50 -0600, Doug Tody wrote:
>> Hi Pedro -
>>
>> This topic - the new DAL service profile, including getCapabilities
>> etc. - goes back to at least the 2006 interop in Victoria, where it was
>> discussed in the full DAL sessions and in the plenary. The approach is
>> based on OpenGIS and was built into the SSA protocol about that time.
>> We (you and I) have also discussed these issues in connection with
>> SLAP, with the conclusion that SLAP would wait to update to the new
>> service profile and getCapabilities, after it was developed and tested
>> within SSAP.
>>
>> It is true that the most recent discussion of service metadata
>> and getCapabilities has been mostly between Ray and myself (as the
>> Registry and DAL chairs) over the past several months. However,
>> this discussion has thus far mainly been on the high level issues,
>> such as the scope of service metadata, and these have had adequate
>> exposure elsewhere, most recently in the TEG forum (where this has come
>> up repeatedly, e.g., in the description of the DAL service profile).
>> The related issue of dataset metadata, and the relationship between
>> service and dataset metadata, has also been discussed. Thus far,
>> I have seen almost no response from the TEG to anything of this sort
>> which I have posted.
>>
>> Given that this overall approach has been out for discussion for about
>> a year, and is now implemented in actual protocols and implementations
>> (SSAP), I can't see making major changes at this point. The details
>> of what getCapabilities contains and how it is used, however, are
>> still open for discussion. As I say, we have a session dealing with
>> getCapabilities scheduled for Beijing (DAL-1), where Ray and probably
>> some other registry folks will be present.
>>
>> Regarding stageData, the concept for this has been out since SIA 1.0;
>> there is a section on it in the SIA specification. It has never been
>> implemented as we have not had the low level technology available to
>> do so. The role of this in the DAL service profile is well established
>> at this point, however the details are still TBD, and are now being
>> considered. The concept was gone into in some detail again within
>> the TEG in the TAP design study which I posted earlier this month.
>> It was also discussed in the GWS list a month ago in connection with
>> the REST discussions. There has been additional discussion in the
>> past week, most of it in the context of the IVOA Assessment over the
>> past week, which you will have seen (I also copied a section of this
>> to the TEG as a heads-up). Guy, Matthew, and myself have had a bit
>> more discussion in private emails as well. We plan to continue this
>> in the DAL and GWS sessions in Beijing.
>>
>> Substantive discussion of this would be welcome. There is plenty of
>> material out there to review, and has been for some time.
>>
>> - Doug
>>
>>
>>
>> On Wed, 25 Apr 2007, Pedro Osuna wrote:
>>
>>> Doug,
>>>
>>>
>>>> getCapabilities is introduced in SSAP and has been under discussion
>>>> between DAL and Registry for some time.
>>>
>>> unless I have been unable to find it for any reason, we (VOQL) have not
>>> been involved in these discussions. I reckon that if this is going to
>>> affect in any way the TAP, we should have some word to say in the
>>> definition of such a big thing. I was worried by your previous statement
>>> (on the getCapabilities issue):
>>>
>>> [...]To summarize our current thinking (which will be cast in stone
>>> shortly due to the need to get SSAP out)[...]
>>>
>>> I would not like something to be cast on stone when we have not had the
>>> chance to discuss about it in a broad (I would say, whole DAL, whole
>>> Registry and whole VOQL at least) audience and it might affect some of
>>> our deliverables. I still do not know who you mean when you say "our".
>>> Is that yours and Ray's?.
>>>
>>> I have checked, and there don't seem to be any inputs in the dal forum,
>>> nor in the registry forum about the getCapabilities, although I can
>>> admitedly be wrong.
>>>
>>>> stageData is being actively discussed now between DAL and GWS (Guy).
>>>
>>> See same comments as above.
>>>
>>> Note that to avoid unnecessary misunderstandings, I have copied this
>>> mail to the IVOA TCG Chair for his information.
>>>
>>> Roy: you can check previous mails if you need at:
>>> http://www.ivoa.net/forum/voql-teg/
>>>
>>>
>>> Cheers,
>>> P.
>>>
>>>
>>>
>>>
>>> On Tue, 2007-04-24 at 09:34 -0600, Doug Tody wrote:
>>>> On Tue, 24 Apr 2007, Pedro Osuna wrote:
>>>>
>>>>> 7) Clarify point with Doug: in which forum is the getCapabilities
>>>>> and stageData (and/or others) being discussed?. Ask for inclusion
>>>>> on it if relevant.
>>>>
>>>> getCapabilities is introduced in SSAP and has been under discussion
>>>> between DAL and Registry for some time. We have to finalize this for
>>>> the SSAP WD shortly (I am working with Ray directly on this one; Ray
>>>> will also join us in the DAL-1 session in Beijing to discuss this).
>>>> We will want the same mechanism in all the DAL services. It returns
>>>> only service metadata.
>>>>
>>>> stageData is being actively discussed now between DAL and GWS (Guy).
>>>> The mail I forwarded earlier summarizes what is planned, but we are
>>>> still actively discussing this. We will want to implement stageData
>>>> initially in both SIAV2 and (presumably) TAP.
>>>>
>>>> There is also the getAvailability method, used to monitor service
>>>> health and availability (discussion between DAL and GWS).
>>>>
>>>>
>>>> For TAP, the key issue would appear to be the scope of queryData,
>>>> and whether this can be used as a uniform mechanism to return both
>>>> table data and metadata (this does not mean we would have to permit
>>>> ADQL for metadata queries). In the other DAL interfaces, it is
>>>> used for discovery, to return dataset metadata, and to propose/plan
>>>> data products (often virtual) which can be computed and returned.
>>>> All of these functions return the query results as a table, hence
>>>> it is reasonable to use the same mechanism to directly query a data
>>>> table as well. In the simplest case of a queryData on a single data
>>>> table, this reduces to what is essentially a cone search, but with
>>>> a somewhat generalized set of input parameters, plus an ADQL option.
>>>>
>>>> - Doug
> --
> Pedro Osuna Alcalaya
>
> European Space Agency (ESA)
> European Space Astronomy Centre (ESAC)
> Research and Scientific Support Department (RSSD)
> Astronomy Science Operations Division (SCI-SD)
> e-mail: Pedro.Osuna-at-esa.int
> Tel + 34 91 813 13 14 Fax: +34 91 813 11 72
> -------------------------------------------------
> European Space Astronomy Centre (ESAC)
> P.O. Box 50727
> E-28080 Villafranca del Castillo
> MADRID - SPAIN
>
> ================================================================================================
> This message and any attachments are intended for the use of the addressee or addressees only. The
> unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content
> is prohibited. If you received this message in error, please delete it from your system and notify
> the sender. E-mails can be altered and their integrity cannot be guaranteed. ESA shall not be liable
> for any e-mail if modified.
> =================================================================================================
>
Received on 2007-04-25Z18:31:48