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

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 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?

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:16:10 UTC