to use xsd:decimal as the datatype for any number,
to use an additional property to encode the value as a number in scientific notation, easily verifiable by humans - let's call this the 'proofValue'.
The changes to the units ttl file were made in order to test the SHACL constraint, hopefully covering all the possible cases. The proofValues are added using the property qudt:conversionMultiplierInScientificNotation.
Details:
encoding the proofValue as an xsd:double has the added benefit of syntax checking by the RDF engine.
the SHACL rule takes the string literal value of the proofValue, transforms it into a digital number in non-scientific notation and compares that to the string literal value of the number in question
Note:
This is just a proof of concept - if adopted the question would be: do we use one proofValue property per value property, or do we use one property holding all proofValues for all numbers in the entity.
The former is straighforward based on this PR. The latter would require a format for the proof values property, such as ([property] [proofValue] [newline] )*, and the SHACL rule would have to do some more work (splitting by newline and selecting the value of [property] for each line).
This is a suggestion regarding #798
The suggestion implemented in this DRAFT PR is
The changes to the units ttl file were made in order to test the SHACL constraint, hopefully covering all the possible cases. The proofValues are added using the property
qudt:conversionMultiplierInScientificNotation
.Details:
Note: This is just a proof of concept - if adopted the question would be: do we use one proofValue property per value property, or do we use one property holding all proofValues for all numbers in the entity.
The former is straighforward based on this PR. The latter would require a format for the proof values property, such as ([property] [proofValue] [newline] )*, and the SHACL rule would have to do some more work (splitting by newline and selecting the value of [property] for each line).