ModelInstance

[mcdittmar]

This element seems to be a 'catch-all' for any modeled data product. In that regard, it is very similar to Markus' recommendation, where there is an undescribed class where you then "put appropriate object here".

[lmichel]

This is a catch-anything-serialized-with-the-same-syntax element

In that regard, it is very similar to Markus' recommendation,

I'm not sure @msdemlei will be enthusiastic with this way to proceed, bu the idea is the similar anyway.

where there is an undescribed class where you then "put appropriate object here".

Exactly, there are 2 use cases that justified this feature:

• Attach a Provenance to a Mango instance
• Attach TS/SED/Spectra to a source

It is to be noted that the such associated data can be delivered by web services; in that case, we would have to use WebEnpoint instead of ModelInstance

[mcdittmar]

Right, so this is another case in the discussion about model dependencies. A more formal approach would be:

• VOModelInstance references ds:DataProduct
  • requiring that things that can go at ModelInstance (TS|SED|Spectra) extend the ds:DataProduct base class.
  • Note: currently there is a cube:DataProduct, but I've expected to move this as an abstract base in Dataset. (DataProduct references a DatasetMetadata instance). It is extended for SparseCube and NDImage.
  • This is the hook we used in the prototype TS model to accommodate the case type "Time series of Spectra"

For the case I'm currently working.. I am associating a cube (TS/LightCurve) to each Master Source record. Which is when I noticed that, technically, my TS is not a ModelInstance, so should not be allowed (validation wise).