Identification model in VO Spectrum Model

[Pavlos Protopapas]

Hi

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 ?

Pavlos







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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20061025/16cd8e7f/attachment-0001.html>