[utypes] (no subject)

[Mireille Louys]

Hi Omar,

here are a few comments on your proposal.
I find the graphs useful to explain the useful bits of an IVOA data  
model and how a serialisation may be derived from it.


On versioning:
I think a version number should specify a data model version instead  
of versioning individual entities.
A data model may need changes in a few of its entities , and therefore  
be updated in a new version of the data model.

Allowing a version number to each entity breaks the design logic of  
data models and may produce non interoperable aplications/services .

We dicussed how a customised new entity could be derived from an  
existing one in order to extend data models for some specific  
configurations. This means this extra entities are specified outside  
any data model , but documented in the service , application that is  
using it.
I think this can be hooked as a derived class of entity in a specific  
CustomisedEntity


more comments inserted below...

thanks for iterating on this on the list.
Cheers , Mireille


Omar Laurino <olaurino at head.cfa.harvard.edu> a écrit :

> Hi All,
>
> I am attaching two diagrams. One is an abstraction of the Data Modeling
> process and might not be included in the UTypes document. However, the
> Utypes document should refer to that diagram (maybe a Note?).
...
> Here is a description of the DM diagrams: a StandardDocument contains one
> or more Namespaces (Characterization, STC, Target, Spectrum, etc.). Each
> namespace has a label (char, stc, target, spec) which is used to resolve
> the Entities defined in each Namespace. For instance, char:Accuracy and
> spec:Accuracy are different Entities (different concepts).

> Also, Entities
> have versions. Thus, the qualified name of an Entity is ns:Name-x.y (e.g.
> char:Accuracy-1.0).
I am not so found of versioning elements , data models have been build  
for specific purposes and follow some logic.

You can serialize a SerializableEntity, which is an
> Entity with attributes that have concrete values: in particular they have
> UtypedValues, i.e. values associated to a Utype string. This values hold a
> reference to the actual attribute they refer to, through their utype. A
> serialization (a Document, or file) holds several instances of an Entity,
> one for each row.
Attribute is very ambiguous here. what about data model field , as  
part of a data model Entity?
> It also has a set of declarations. Note that the
> declaration is one of the few differences between my model and what we
> currently, implicitly, do. The other subtle differences should be clear in
> the following description.
>
What we currently have to correspond to your list of 'declarations'  
would be an XML instance document or a VOtable .

In the Class "Utypedvalue", the field 'attribute' is in fact a  
reference to the "Attribute" Class : it could appear as attributeRef,  
for instance ( or DataModelFieldRef)

...
> So, Entities have Attributes, according to the DM diagram. In my prototype,
> here is a description of a sample Namespace in a simple ASCII format
> (constraints are not included):

I agree with this reference to the attributes defined in the model .
This helps to distinguish the role of a Utype as "semantic path" in  
the data model from a data type (double, pair of double, ISOTIME  
string etc...) which is explicitely defined in  
datamodel::Attribute.dataType.


Mireille.