Prov-WD: valueType in ValueDescription and ParameterDescription unclear

[Ole Streicher]

Ahh, that makes sense. I meant 4.7 "ValueType extends Type", and you are
right, this is not the "ivoa base model". Maybe calling them "value
types" is a bit misleading, and one should rather specify it as "type of
the value: any primitive from the VODML ivoa base model (Lemson and
Laurino et al. (2016))", and/or mention this directly in the text.

Question to all: are quantities (with a directly attached unit) allowed
in ValueEntity? The "unit" field of the description should be empty then
ofcourse.

Best

Ole

On 16.07.19 18:48, Laurent Michel wrote:
> To make sure we are talking about the same think, I was referring to the
> section 5 p56 (The ivoa base model)
> LM
> 
> 
> Le 16/07/2019 à 17:39, Ole Streicher a écrit :
>> 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
>>>>
>