- From: Antoine Zimmermann <antoine.zimmermann@emse.fr>
- Date: Sat, 25 Jul 2020 13:01:06 +0200
- To: Hugh Glaser <hugh@glasers.org>, Eric Prud'hommeaux <eric@w3.org>, Semantic Web <semantic-web@w3.org>, Maxime Lefrançois <maxime.lefrancois@emse.fr>
Le 25/07/2020 à 10:59, Nicolas Chauvat a écrit : > Hi, > > Thank you Antoine and Maxime for the work on ucum and the explanations > that I find very helpful. > > On Fri, Jul 24, 2020 at 09:34:35PM +0200, Antoine Zimmermann wrote: >> <measurement> :value "2.5 m"^^cdt:ucum; >> :precision "1 %"^^cdt:ucum . > > But you could also have: > > <measurement> :value "2.5 m +- 1 %"^^my:measuredatatype > > What would make you chose one over the other ? The fact that ucum is > already available as an extension in your SPARQL engine and that you > do not want to develop a new one ? Can you see other criterions ? > The problem with this is that the semantics is not clear. What value does "2.5m +- 1%" denote? If I measure the length of my table and I find "1 m +/- 0.1%" and someone else measure the table and find "1 m +/- 0.2%", what can we conclude? Can we compare these values? The measure could be an interval, perhaps. It is much more complicated to deal with intervals, and it is often difficult to define the degree of precision. Rather than taking a sharp decision on this, we prefer to externalise the problem of precision. We only rely on things that are well defined, namely numbers and unit codes. In terms of implementation, integrating cdt:ucum in a SPARQL engine is straightforward, given that you have a library for UCUM in your programming language (which probably is the case). At least, my colleague Maxime could do this integration in Jena in just a few days. Integrating measurement with precision (assuming they are interpreted as intervals, which is not necessarily obvious) would be much more work. What would be the result of "2.5m +- 1%"^^my:measuredt < "2.51m +- 1%"^^my:measuredt? Nonetheless, as a research question, this may be an interesting thing to investigate. --AZ
Received on Saturday, 25 July 2020 11:01:22 UTC