- From: Pierre-Antoine Champin via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Oct 2022 13:12:15 +0000
- To: public-dxwg-wg@w3.org
Another option would be the following: define a new RDF datatype dcat:decimal - its value space is exactly the same as xsd:decimal (si that it is semantically backward compatible with xsd:decimal) - its lexical space includes the lexical space of xsd:decimal (roughly: /[-+]?[0-9]+(.[0-9]+)?/), but also contains E notations (roughly: /[-+]?[0-9]+(.[0-9]+)[eE][-+]?[0-9]+/) (really, I see no reason why the E notations were not included in the lexical space of xsd:decimal !...) Then change the range of all concerned dcat properties from xsd:decimal to dcat:decimal. As stated above, this is not a breaking change (xsd:decimal is semantically a subtype of dcat: decimal -- even syntactically, any valid xsd:decimal value can be "cast" to a dcat:dedimal without changing its meaning). This way, the literals produced by JSON-LD processor would be valid when the original value was any JSON number... @iherman any opinion on this? -- GitHub Notification of comment by pchampin Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1536#issuecomment-1283993051 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 19 October 2022 13:12:17 UTC