utype for STC region in SIAP query response

[Douglas Tody]

Hi Norman -

I hope the holidays are treating you well.

On Mon, 19 Dec 2011, Norman Gray wrote:
> On 2011 Dec 19, at 01:33, Douglas Tody wrote:
>
>>> It cannot be the UTYPE, if every data model uses a different UTYPE for a
>>> footprint.
>>
>> Well this is the key point; yes we can standardize the core model and
>> the UTYPE used for this purpose and they do not need to be different
>> despite being included in different models.  Yes the namespace (dataset
>> class or context) may be different for different classes of data, but
>> the UTYPE, minus the namespace prefix defining the context where it
>> used, can be the same and can be defined to meant the same thing.  This
>> is how UTYPEs have historically been used up to now, and we can
>> formalize this further in the UTYPE spec (hopefully without
>> over-complicating the mechanism).
>
> What would this achieve?
>
> Say an application comes across a UTYPE
>
>    foo:SpatialAxis.Coverage.Support.Area,
>

> and suppose that the 'foo' namespace was standardised after the
> application itself was written, or since it was last updated.  Should
> that application treat this as a footprint?

In the first place lets not forget that the problem we need to solve
here is fairly limited.  VO only requires half a dozen or so interfaces
for the major classes of data (at least for observation-based data).  We
have nearly all of them now and they are already fairly consistent.  We
can eventually make them fully consistent in terms of the standard
metadata and submodels (Char etc.) included in each object class.  It
does not have to be all that complicated and the mechanism should not be
allowed to get too complicated, at least not for the standard core
metadata.

> I presume the answer is 'no'.  In that case, the application is stuck --
> it has no idea what to do with this UTYPE, and cannot have any idea,
> until the application author reads the relevant standard and encodes it
> in an update of the application, which is then released and distributed.
>
> If the answer is 'yes', because 'SpatialAxis.Coverage.Support.Area' is
> expected to mean the same thing everywhere, then it is clear that there
> is no point in having namespaces, and people should stop talking about
> them.

Neither of these options is quite true - Utypes from submodels can be
standardized and reused in larger models, but we still need namespaces
to describe and understand entire new dataset classes and their
relationships.

Namespaces (as well as more formal rules for how to reuse existing
standard data models in new models) can provide a solution to this
problem.  A data model namespace, at least within the DAL interfaces,
corresponds to an object class like Spectrum, SSA query response,
Observation/Dataset, etc.  Usually a new class extends an existing one
inheriting the bulk of its attributes, and this relationship can be
specified as part of the computer readable namespace metadata.

Hence if a new dataset class appears which an application is not aware
of, but it extends an existing well known class, then the application
can assume that any standard Utypes defined by the parent class are
inherited by the new class if the Utype name does not change (assuming
we define that as a composition rule).  So long as the application
understands this relationship, represented in a computer readable form
by the runtime namespace definition, it will already understand much
about the new dataset class.  Of course any new semantics (object
attributes or Utypes, modified semantics for same, or larger constructs
relating to the new object) will not be knowable without fully
understanding the new class of data, but the generic stuff will be well
defined.

So for example Spectrum extends "Spectral" (the new Spectral DM).  Then
later we add TimeSeries which also extends Spectral.  An application
which understands Spectral already understands much about TimeSeries, in
particular anything specific to the underlying generic model.
Ultimately we can extend this to the underlying Observation/Dataset
model (which is the basis for all the DAL interfaces) once the data
models eventually stabilize and converge.

In theory we could instead compose an object instance by instantiating
external submodels like Char, Photometry, STC, Target, etc. in
combination with some custom object metadata.  But this is difficult and
probably overkill - too complex.  It is simpler to incorporate subsets
of well defined versions of these models into a unified model such as
ObsCore, SpectralDM, or whatever, otherwise we have death by version
confusion and model bloat (including stuff not needed by the specific
use case).

This larger problem is really a DM architecture issue as we discussed in
Pune.  Formalizing the Utype mechanism is part of it.  What we have
already works fairly well but it would be good to clarify the conceptual
model at the basis for all this.

 	- Doug