Prov-WD: valueType in ValueDescription and ParameterDescription unclear

[Ole Streicher]

Hi Laurent,

Laurent MICHEL <laurent.michel at astro.unistra.fr> writes:
>  "VODML value type, see Lemson and Laurino et al. (2016)"
>
> should be replaced with
>
>  "value types of the VODML ivoa base model, see Lemson and Laurino et
> al. (2016)"

This would still not solve the issue, since it allows complex types
(DataType, which are ValueTypes). The example in the VO-DML standard
(pg. 36) is a DataType SkyCoordinate, "defined as a longitude/latitude
pair with a reference to a reference frame that allows the
interpretation of the values of the attributes".

Do we really want to handle this in our ValueEntity? While for the
primitives, the string representation is trivial (although is should be
defined somehow), it is just undefined for such a beast. So, an
interoperable client would have no chance to interpret this. It is also
unclear, *what* is written in that field: The id? "ivoa:string"
resp. "mymodel:SkyCoordinate"?  (... and how is this resolved?) Or just
the name?

IMO this would make the implementation here unnecessarily complex and
removes interoperability, without having a use case here. We can reach
all our goals if we restrict this to the basic types (string, datetime,
integer etc.). If really needed, this can be extended with some care.

Best regards

Ole

> Le 16/07/2019 à 08:42, Ole Streicher a écrit :
>> Good morning,
>>
>> the attrbutes valueType in ValueDescription and ParameterDescription
>> have the description (2.6.2 "ValueEntity and ValueDescription classes",
>> table 18, pg.28):
>>
>> "VODML value type, see Lemson and Laurino et al. (2016)"
>>
>> I doubt that this is usable, since it basically allows *all* VO-DML
>> value types:
>>
>>   * PrimitiveType
>>   * Enumeration
>>   * DataType
>>   * ObjectType
>>
>> Having some complex ObjectType stored in a Value is however not
>> interoperable, since the serialization as string is not at all defined,
>> which makes it impossible for a client to interpret the value. It is
>> also unclear what to fill into that field. The hwole VO-DML id? What
>> about locally defined ObjectTypes?
>>
>> Also I doubt that we shuld allow f.e. Quantities here (since they
>> duplicate the unit).
>>
>> IMO the only cases we have so far are the simple types: strings and
>> numbers (integer and floating point). We should restrict here to those,
>> or significantly improve the documentation.
>>
>> Best
>>
>> Ole
>>