Identification model in VO Spectrum Model

[Doug Tody]

On Wed, 25 Oct 2006, Pavlos Protopapas wrote:
>
> First I apologise for referring to the old version. Somehow
> I sent this message 3 days back and then I received a
> notification that it was not delivered and then I resend it.
> So you may get another copy of the same message again.
>
> Now about the issue of ID that I raised.
> A simple scenario. Lets say somehow
> I get two spectra. I do not know how and why. May be
> my program generates them therefore SSA was not involved
> in this. Now I want to make sure that I do not have duplicates.
> I do need an ID, don't I ?

Maybe so.  In general with VO, data over-the-wire is not supposed to be
persistent, and one should not separate the standard metadata in the
query response from the dataset generated by the service.  But this could
be an issue with spectra since the native data can be inaccessible (via
standard interfaces) or difficult to deal with.

It may be that a different mind-set is needed when dealing with data
within the VO.  In general one should always try to go through a
VO service to get at the data, and instead of persisting datasets,
pass dataset identifiers (pointers) around rather than the datasets
themselves.  Datasets will always be persisted/cached for some time
of course during analysis, but hopefully this is done in a VO context
where the higher level metadata is not lost.  If you look only at a
single dataset you *will* lose some information, even if the dataset
is based on a standard data model and metadata.

 	- Doug


> On 10/25/06, Doug Tody < dtody at nrao.edu> wrote:
>> 
>> Hi Alberto -
>> 
>> On Wed, 25 Oct 2006, Alberto Micol wrote:
>> > Wouldn't, hence, be possible to specify (in the protocol/DM)
>> > the  different available contexts (adding for example an enumerated
>> > CONTEXT attribute), and to define for each of them the proper
>> > mandatory/optional/whatever fields?
>> >
>> > With that, clients will be able to specialise on a given context
>> > based on solid grounds, and I find this possibility extremely valuable.
>> >
>> > Someone could argue that we cannot imagine all the possible usages
>> > of a DM a priori; true! but on the other hand, as soon as someone comes
>> > up with a new context, it will be not difficult to inlude it in the
>> > next release.
>> 
>> Frankly, I think it is pointless to try to specify in a general data
>> model what is required/optional (except maybe for direct data analysis
>> upon a dataset instance)); this needs to be done for each specific
>> application of the data model.  The SSA protocol is one such case,
>> although even here there are additional contexts for different types of
>> data or services.  It is difficult to deal with all of these without
>> overly complicating the specification, however we have tried to do
>> so by defining protocol-wide requirements with additional written
>> narrative mentioning the special cases or contexts.
>> 
>> It would be good to move this discussion to a more concrete level;
>> I suggest reviewing the protocol document and commenting on what is
>> required for a minimally or fully compliant service for the specific
>> use-case of data discovery and selection.  (Followups on this specific
>> topic should go to the DAL list).
>>
>>         - Doug
>> 
>> 
>