Prov-WD: valueType in ValueDescription and ParameterDescription unclear

[Laurent Michel]

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

-- 
jesuischarlie/Tunis/Paris/Bruxelles/Berlin

Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg