[Cube/vo-dml] ivoa datatypes

[Gerard Lemson]

HI Pierre
Thanks for your feedback.

> 	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.

To be even more precise, it was during the tiger team discussions in Nov 2012 that you made your comments regarding a VOTable mapping that I had created as a proof of concept. Your point was accepted and a first version of a model with these quantity types that should serve as the approach to solve the problem was part of the proposal to the IVOA in Heidelberg already. 

> 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 ? ...).
> 
Instead of using the term duplicate, I would say that we try to represent these commonly used primitive concepts in a model based on the proposed VO-DML meta-model. By defining these basic types in a single, small and *standard* model, that SHOULD be reused by other VO-DML models, those models do not need to create their own quantity types. There are currently already quite a few of such cases. See for example PhycialQuantityDouble in PhotDM and spectral line model. Or fieldType and paramType in the spectrum data model. Or various types in STC.
VO-DML allows such models to instead use the common standard. With such a standard set of types used by all models, we can in the UTYPE spec make special statements that attribute with these datatypes can be mapped directly to a FIELD or PARAM; indeed precisely so that the actual ucd and unit of the quantity can be defined in the FIELD or PARAM metadata, just as its value is defined in the <TD> (or @value for PARAM). And no separate mapping is required.

And please note that the full content of the model is put forward as a proposal and makes no claim to be complete, or that all its types are necessary. I personally  think these types need be no more scary than those in VOTable or any other language. The primitive types have representations in XSD, SQL/ADQL, Java or other languages. Datetime is there to represents general date-time combinations, like a java.util.Date (something votable is lacking). anyURI is there because many attributes in the VO already use such a type.
The numeric types correspond to the common math types, integer, real, complex etc, rather than to their serialized/computer representations (short, int, long, float, double). The background of this is that for most modeling use cases it is not necessary to prescribe the precise precision a certain attribute representing some integer or real concept should have. It is rarely necessary to declare that a certain attribute MUST be a single rather than a double precision floating point number(*). Hence we choose the name 'real'. A concept familiar to everyone I would hope. 

But again, the content of the model should be considered  open for discussion together with the VO-DML spec itself.
Do we need rational and complex? Or decimal ? I don't know. Same for duration and Identity (already cut form the model as displayed in appendix E of the spec. 

(*) If it turns out to be necessary one can use constraints in certain cases, or the type system can be extended if all think it useful.

Cheers
Gerard


> 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
>