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

Little complement:


Le 21/07/2020 à 19:15, Antoine Zimmermann a écrit :
> Le 21/07/2020 à 17:38, Peter F. Patel-Schneider a écrit :
>> 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.

The previous version of the spec was:
https://ci.mines-stetienne.fr/lindt/v2/custom_datatypes

The definitions of the value space and lexical-to-value mappings were 
not very precise, and not in line with what the UCUM spec says. UCUM has 
a set of base units that is not the same as the base units of the SI 
standard.

The new definition is more precise and aligned with UCUM semantics.

> 
> The specific datatypes are actually not really stable and will be 
> externalised in a future version. They were added because the 
> implementation of UCUM we are using have specific support for all these, 
> so we initially thought we would assign IRIs to them. But this set is 
> rather arbitrary, so we will make them optional and extensible. The 
> specification of these types is based on a former draft and we did not 
> update them because we were planning to remove them from the core 
> specification.
> 
>>
>> As well, why are real numbers used when only decimals can be written?

In fact, this is not correct. In UCUM, the constant π (noted "[pi]" in 
UCUM) is defined. It can be used as a multiplier to any unit and its use 
may result in non decimal values in the (value,baseunit) pairs. Of 
course, a lot of real numbers are still impossible to write, but it is 
much more convenient to define it this way.


--AZ


> 
> What problem does it bring? The value space of owl:real contains all the 
> real numbers and has an empty lexical space. Maybe I'm missing something 
> and this has weird consequences, but I do not see them. >
> 
> --AZ
> 
> 
>>
>>
>> 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
>>>>
>>>
>>
> 
> 


-- 
Antoine Zimmermann
ISCOD / LSTI - Institut Henri Fayol
École Nationale Supérieure des Mines de Saint-Étienne
158 cours Fauriel
42023 Saint-Étienne Cedex 2
France
Tél:+33(0)4 77 42 66 03
Fax:+33(0)4 77 42 66 66
http://zimmer.aprilfoolsreview.com/

Received on Tuesday, 21 July 2020 17:36:41 UTC