@edeutsch and others have expressed the opinion that the purpose of the value_type_id field is to help computational consumers/readers of the data (e.g. the UI) know how to interpret string. e.g to unwind a CURIE, make a hyperlink for a url, or simply display free text string to the end user. Goal is to help the consuming agent do the most sensible thing with the value in this field.
On the May 23 2023 EPC Call, there was general consensus around this opinion, and that we should add clarifying text and/or formal constraints to the definition of this field in the TRAPI spec (e.g a formal enumeration to constrain values of this field so they are entered consistently).
An initial decision on the 5-23-23 EPC call was to use the built in data types in the linkml model (link, link) - the metamodel underlying biolink, and from which biolink imports its data types) . . . or some useful subset of these. And capture them as curies such as "linkml:Uriorcurie" - where we can expand the linkml prefix to into a resolvable URL as needed so users can see where these came from and how they are defined.
Current linkml data types include:
String: A character string
Integer: An integer
Boolean: A binary (true or false) value
Float: A real number that conforms to the xsd:float specification
Double: A real number that conforms to the xsd:double specification
Decimal: A real number with arbitrary precision that conforms to the xsd:decimal speci...
Time: A time object represents a (local) time of day, independent of any particular...
Date: a date (year, month and day) in an idealized calendar
Datetime: The combination of a date and time
DateOrDatetime: Either a date or a datetime
Uriorcurie: a URI or a CURIE
Uri: a complete URI
Ncname: Prefix part of CURIE
Objectidentifier: A URI or CURIE that represents an object in the model
Nodeidentifier: A URI, CURIE or BNODE that represents a node in a model
If/when we settle on final terms, we may want to update the TRAPI spec to require use of these terms (informally in the description or formally by creating an enumeration).
@edeutsch and others have expressed the opinion that the purpose of the
value_type_idfield is to help computational consumers/readers of the data (e.g. the UI) know how to interpret string. e.g to unwind a CURIE, make a hyperlink for a url, or simply display free text string to the end user. Goal is to help the consuming agent do the most sensible thing with the value in this field.On the May 23 2023 EPC Call, there was general consensus around this opinion, and that we should add clarifying text and/or formal constraints to the definition of this field in the TRAPI spec (e.g a formal enumeration to constrain values of this field so they are entered consistently).
An initial decision on the 5-23-23 EPC call was to use the built in data types in the linkml model (link, link) - the metamodel underlying biolink, and from which biolink imports its data types) . . . or some useful subset of these. And capture them as curies such as "linkml:Uriorcurie" - where we can expand the linkml prefix to into a resolvable URL as needed so users can see where these came from and how they are defined.
Current linkml data types include:
If/when we settle on final terms, we may want to update the TRAPI spec to require use of these terms (informally in the description or formally by creating an enumeration).
See related ticket in the Biolink Repo here: https://github.com/biolink/biolink-model/issues/1106