Time/Target mandatory

Markus Demleitner msdemlei at ari.uni-heidelberg.de
Fri Aug 15 01:02:19 PDT 2014


Dear DM WG,

On Thu, Aug 14, 2014 at 12:41:36PM -0400, CresitelloDittmar, Mark wrote:
> Just to re-state. The real issue is that you need to cast your
> theoretical data to an observational model, because that is all

Well -- so are theoretical spectra considered in scope for the SDM2
or not quite?  If they're not, my points are of course moot.

>   + generic models
>        perhaps these values just don't apply here.  In which case, what you
>        are doing
>        seems the most reasonable approach. (Nan/Null)

That of course again poses the question: What does "mandatory" mean?
If I'm allowed to put NULLs in there, I'm fine, but I expect client
developers will cringe; after all, the whole point of making something
mandatory is to make their lives easier by sparing them complicated
logic handling missing values for whatever is mandatory.

So -- *if* NULLs are allowed as values for mandatory fields, that
needs to be prominently advertised.  And I personally would
appreciate a statement if there's a difference between

  (<key>, <value>) missing in container format

and

  (<key>, NULL) serialised.

On the other hand, I think we'd be doing ourselves a favour if we
outlawed NULLs in mandatory fields and only made items mandatory for
which we're confident we're not blocking use cases we'd like to cover.

> > or yet something else -- or maybe drop the requirement for
> > Target.Name entirely?  What, by the way, is the rationale for having
> > it mandatory?
> >
> 
> As for rationale.. I don't have any.  It has been mandatory, so it remained
> so.
[...]
> So, IMO again, the best value is whatever completes the sentence:
>   "This is a Spectrum of _______"
> 
> If "model star" best answers that, fine.  If something more specific...
> that's fine to.
> I don't think it ever needs to be empty, because it is certainly a spectrum
> of something.

That's all the rationale I could wish for.  Makes perfect sense
to me.

> It does not seem to be something intended for query.. so no formal
> syntax/content

Ah, I disagree on the "intended for query".  SSAP has always allowed
searching by target name, although it's hard doing this in a useful
way just now (essentially, we're missing a reliable way of
discovering object names available).  In Planetary Sciences,
searching by target name is yet more important.

But the making things searchable is probably more on the access
protocol than on the data model, unless there's an obvious and unique
prescription for the domains or serialisations.  And object "object
name" and "unique" just don't go together, I'm afraid.  So, I'm fine
with not giving a vocabulary there.  An example usage from a theory
use case in the document would still be useful, though.


Cheers,

       Markus



More information about the dm mailing list