[Cube/vo-dml] ivoa datatypes

[Pierre Fernique]

Le 25/04/2014 10:55, Gerard Lemson a écrit :
> Hi
> Some comments to Mark's email.
>
>>    For the cube model work, I have baselined all the related models to a common
>> set of base datatypes.  I selected the 'ivoa types' model from vo-dml in order to
>> facilitate efforts to represent these models in that framework.
>>
> As proof of concept of VO-DML, an attempt was made (already during the utype tiger team effort!) to port most if not all of the IVOA data models to that representation. Care was taken also to try to link the different models according to the VO-DML modelimport mechanism. The results of this work can be found in the various sub-folders under https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/models. Its contents will be described on the VO-DML wiki page soon.
> No guarantee is given that the port is exact, nor necessarily 1-1, as often interpretations were needed to map the models to the formal VO-DML representation.  We have asked before, in particular in Heidelberg, that an effort should be made to do this more formally. If only because one of the requirements on VO-DML is that it can provide models representing the same domain as the existing models do, and preserving as much of the semantics as possible.
>
>>     The current description is here:
>>       https://volute.googlecode.com/svn/trunk/projects/dm/vo-
>> dml/models/ivoa/IVOA.png
>>
> This is not quite complete.
> The "ivoa" model plays a special role in the VO-DML specification.
> It was introduced as a common base model, defining the standard primitive types such as integer, boolean, string etc.
> Using such a common set of primitive types means that at the leafs of a model, in its primitive attributes, we agree on the possible set of types.
> This model SHOULD therefore be used by all other models, using a model import.
>
> The ivoa model also specifies various quantity types that give possibility to add a ucd or unit to some primitive value. These were introduced here, in this common model, as a standard, agreed way to represent quantities. The main reason for introducing them in a common model is that it allows us in the UTYPE specification to map attributes representing such quantities directly to VOTable FIELD-s or PARAM-s, where the ucd and unit attributes are understood to be implicitly mapped to the corresponding attributes.
> (Note, this pattern was the accepted way to deal with an issue noted by Pierre Fernique, see minutes of utypes meetings: http://wiki.ivoa.net/twiki/bin/view/IVOA/UtypeTigerTeamMinTel7)

Dear DM members,

May I precise my position.
I said one year ago that the VO-DML VOTable serialization proposed by 
Gerard tended to move some meta information such as *UCD*, *unit *or 
*datatype *outside the VOTable FIELD entity towards the proposed GROUP 
VO-DML hierarchy extension. I noted that this point would be extremely 
annoying for all VOTable clients such as TOPcat or Aladin for which this 
metadata information must stay in the FIELD entities.
For bypassing this issue, and if I correctly understand the current 
2014-05-03 XML basic IVOA model description 
(https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/models/ivoa/IVOA.vo-dml.xml), 
the "quantity" entry duplicates now the UCD role and unit role.
Personally, I am not sure that this solution to duplicate this kind of 
information will be the more appropriate approach: 1) we redo our VO 
efforts already done on UCDs and units... 2) we will have to manage 
correspondances between FIELD-UCD/FIELD-unit and VO-DML-quantity.  And I 
have to say that the current basic IVOA model appears for me too 
heteroclite to be used without fear: "identity, rational, complex, 
duration, anyURI, boolean, real, nonnegativeInteger, datetime, integer, 
string, quantity". For a no-DM person, it is quite difficult to 
understand why such or such data type is considered as a basic datatype 
(duration ? datetime ? anyURI ?), and why others are not (char ?, range 
? frequency ? ...).

Cheers
Pierre



>
> You can find the various products of the model at volute: https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/models/ivoa/
> These are:
> The formal VO-DML/XML representation of the model: ./IVOA.vo-dml.xml
> The HTML documentation generated from this, which contains the figure Mark pointed at: ./IVOA.html
> The XMI serialization of a UML diagram representing the model, built in MagicDraw CE 12.1: IVOA.xml
>
> Appendix F of the VO-DML spec describes this model and its usage.
>
>
>>
>> Request:
>>
>>    During this effort, there are a couple types that I would like to add to this suite.
>>
>>    1) TimeValue: extends AtomicValue
>>
>>          + value: datetime     # ivoa:datetime primitive type
>>          + unit: Unit              # ivoa:unit primitive type.
> This would be ivoa:quantity.Unit in current version of the model.
> Unit is defined as a sub-type of string with a constraint that it's syntax must follow the definition of a valid unit (defined in VOUnit?)
>
>>
>>        This could be under Quantity (TimeQuantity) or separate since I expect the
>> 'units' attribute
>>
>>        would be more restrictive than the generic Unit... to just the time domain.
>>
> I don't know whether this would be added as a separate type, or whether it is the task of an attribute definition to decide something is a Time and possibly constrain its unit values? Common modelling issue.
>
>>     2) URL
>>
>>         I would prefer to have a type for URL distinct from anyURI, to make the
>> distinction more clear in the models (rather than relying on qualifying text).
>>
> What would be the distinction between URL and anyURI?
> At some point the usage of the type is important in deciding the semantic meaning of a value (== instance of value-type)
> For example we will likely never have separate types representing age, or mass or length. All of these are attributes with datatype ivoa:real or ivoa:quantity.RealQuantity. There we leave it up to the definition of the attribute to define the semantic meaning of, as well as setting constraints on the value.
> What is different in the  difference between URL and anyURI
> Cheers
> Gerard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20140505/8a9e09ef/attachment.html>