Re: Blank nodes must DIE! [ was Re: Blank nodes semantics - existential variables?]

I looked over the datatype specification.

I was puzzled by the relationship between the general datatype and the
specific datatypes.   It would seem to me that the denotation of "5
m"^^cdt:length should be the same as "5 m"^^^cdt:ucum but the former is a
length as defined by ISQ and the latter is a pair consisting of the real
number 5 and meter. 

As well, why are real numbers used when only decimals can be written?


peter


On 7/21/20 8:35 AM, Antoine Zimmermann wrote:
> Regarding physical quantities, such as "5 inches", etc., my colleague Maxime
> Lefrançois and myself coauthored a specification for a datatype for physical
> quantities [1]. It is quite simple: we reuse the Unified Code for Units of
> Measurement (UCUM), a standard that is used in many scientific applications,
> and combine it with a number:
>
> <QUANTITY> ::= <NUMBER> <SPACES> <UCUMCODE>
> <NUMBER> ::= xsd:decimal(('e'|'E')xsd:integer)?
>
> Since UCUM has a well defined semantics, so does our datatype. Better, since
> UCUM is implemented in many programming languages, my colleague Maxime could
> easily integrate it into Jena and its SPARQL engine [2].
>
> So, with our Jena fork, one can write:
>
> SELECT ?planet WHERE {
>   ?planet a ex:Planet;
>     ex:diameter ?s .
>   FILTER(?s > "2e11 mm"^^cdt:ucum)
> }
>
> This works if the size of the planet is encoded as a cdt:ucum, no matter
> what unit one is using. One can even use "link for Gunter's chain" (unit
> "[lk_us]"), or "cubic meters per acre" (unit "m3/[acr_us]") [3], which are
> both units of length.
>
> With some of our industrial partners, we are using this for energy data, and
> they seem to be very pleased with this approach, compared to an
> ontology-based approach.
>
>
> [1] https://w3id.org/lindt/custom_datatypes#ucum
> [2] You can try it at https://ci.mines-stetienne.fr/lindt/playground.html
> [3] Try this query in the playground:
>
> """
> PREFIX iter: <http://w3id.org/sparql-generate/iter/>
> PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
> PREFIX cdt: <http://w3id.org/lindt/custom_datatypes#>
> PREFIX ex: <http://example.org/>
>
> SELECT ?length ?normalized
>
> WHERE{
>
>   VALUES ?position { "2.7e3 m3/[acr_us]"^^cdt:ucum }
>   # convert to meters
>   BIND("0 m"^^cdt:ucum + ?position AS ?normalized )
>
> }
> """
>
> --AZ
>
> Le 17/07/2020 à 01:57, Cox, Simon (L&W, Clayton) a écrit :
>> Yeah, the atomicity of the chunk is the point. This even applies to
>> quantities. 25.4mm is *identical* to 1” – they are the same thing. Any
>> engine that operates with quantities needs to understand that. ’25.4’ and
>> ‘mm’ cannot be separated. Coordinates are slightly more complex but it
>> comes down to the same thing. A single element within a set of coordinates
>> that describes a position in space is not independent of the other numbers
>> in the tuple, or of the coordinate reference system within which they are
>> expressed. One value should *never* be used independent of the others.
>> Exactly the same position on the earth will be denoted by three different
>> numbers if embedded in a different coordinate reference system. You can
>> only ‘reason’ over them as a group, not individually.
>>
>> *From:*Dan Brickley <danbri@danbri.org>
>> *Sent:* Thursday, 16 July, 2020 23:58
>> *To:* Jeen Broekstra <jeen@fastmail.com>
>> *Cc:* Semantic Web <semantic-web@w3.org>
>> *Subject:* Re: Blank nodes must DIE! [ was Re: Blank nodes semantics -
>> existential variables?]
>>
>> …
>>
>> I believe the big appeal of putting it all into the zone we call "literals"
>> is that you get a kind of atomicity; that chunk of data is either there, or
>> not there; it is asserted, or not asserted. With a triples-based
>> (description of a ) data structure you have to be constantly on your guard
>> that every subset of the full graph pattern is at least sensible and
>> harmless, even when subsetting these chunks is often confusing or
>> misleading for data consumers. I can't help wondering whether notions of
>> graph shapes from shacl, shex (and sparql) could be exploited to create an
>> RDF-based data format which had atomicity at the level of entire shapes.
>>
>> Dan
>>
>>     Jeen
>>
>

Received on Tuesday, 21 July 2020 15:38:21 UTC