Re: Rich literals [was Re: Blank nodes must DIE! ]

If you were truly curious about what the result would be, you would test 
it yourself. You already did the hardest part of the work, that is, 
write the data and the query. Simply copy this to our online playground 
that have been made specially for these questions:

https://ci.mines-stetienne.fr/lindt/playground.html

It is expected that implementations are only supporting a certain 
precision of value, just like XSD indicates that implementations of 
infinite datatypes such as xsd:decimal, xsd:integer, xsd:dateTime can be 
partial (https://www.w3.org/TR/xmlschema11-2/#partial-implementation).

To be safe, a future version of cdt:ucum, especially one that becomes 
standard, could define such "minimal conformance".

At the moment, our implementation is clearly partial to a point that we 
would be glad to have a little man power to extend it a bit (anyone 
interested?).

--AZ

Le 27/07/2020 à 19:36, Peter F. Patel-Schneider a écrit :
> I wonder how your implementation does on some of the trickier comparisons in
> UCUM, such as
> 
> :rad  :angle  "1 rad"^^cdt:angle .
> :radplus  :angle
> "57.295779513082320876798154814105170332405472466564321549160254 deg"^^cdt:angle .
> :radminus :angle
> "57.295779513082320876798154814105170332405472466564321549160236 deg"^^cdt:angle .
> 
> select * where {
>    ?x :angle ?y .
>    filter ( ?y >= "1 rad"^^cdt:angle )
> }
> 
> :au :length "149597870700 m"^^cdt:length .
> :auplus  :length "149597870705 m"^^cdt:length .
> :auminus :length "149597870695 m"^^cdt:length .
> 
> select * where {
>    ?x :length ?y .
>    filter ( ?y >= "1 AU"^^cdt:angle )
> }
> 
> peter
> 
> 
> 
> 
> On 7/27/20 12:34 PM, Maxime Lefrançois wrote:
>> Dear all,
>>
>> Let me try to catch up and answer some of the questions.
>>
>> I used the java ucum implementation [1] developed on top of the Indriya
>> reference implementation of JSR 385 [2]
>>
>> In Apache Jena it's easy to add the support of a new RDF datatype, but:
>>   - I had to change some things inside ARQ to implement ordering,  overload
>> arithmetic operators, etc.  -> this is why our implementation is a fork of
>> Jena, and not a separate library.
>>   - It would be harder and extremely unoptimized to parse datatype IRIs.
>> Still probably possible. I did something similar in [3]
>>
>> So yes @Graham, it's kind of being like https://xkcd.com/1425/ ,
>> but to this I'd add:  cdt:ucum is very simple, elegant, it suits our needs,
>> so I don't see the point of working on any alternative.
>> It was straightforward and quite fast to implement. This makes me think that
>> other RDF processors and SPARQL engines could support it soon.
>> UCUM has implementations for different programming languages
>>   Python https://pypi.org/project/pyucum/
>>   NodeJS https://www.npmjs.com/package/@lhncbc/ucum-lhc
>>
>> I strongly believe that having too many alternatives would probably result
>> in confusion among the users, and work against a wider adoption.
>>
>> [1] https://github.com/unitsofmeasurement/uom-systems/tree/master/ucum
>> [2] https://www.jcp.org/en/jsr/detail?id=385
>> [3] Maxime Lefrançois, Antoine Zimmermann, Supporting Arbitrary Custom
>> Datatypes in RDF and SPARQL, In Proc. Extended Semantic Web Conference,
>> ESWC, Heraklion, Crete, Greece, May 2016
>>
>> Best regards,
>> Maxime Lefrançois
>> MINES Saint-Étienne
>> http://maxime-lefrancois.info/
>>
>>
>> Le lun. 27 juil. 2020 à 18:00, David Booth <david@dbooth.org
>> <mailto:david@dbooth.org>> a écrit :
>>
>>      On 7/25/20 8:41 AM, Hugh Glaser wrote:
>>       > I would like the developers' world of tooling to stay as
>>       > simple as it currently is.  Which to me means anyone wanting
>>       > one of these magic literals of any kind to be used in RDF,
>>       > to provide not only the description for the literal, but
>>       > also define how those literals should be represented in RDF.
>>
>>      Agreed.  I find the idea of rich literals quite intriguing, like the
>>      excellent UCUM work by Antoine Zimmermann and Maxime Lefrançois just
>>      discussed.
>>
>>      I could see rich literals being quite helpful in making RDF easier to
>>      use, provided that the literal<->RDF mapping is available.  This mapping
>>      requires two functions: one from a given literal to RDF, and the other
>>      from RDF to literal.
>>
>>      Ideally, these mapping functions should be defined "in-band" in the RDF
>>      itself, so that data can always be self-describing, and all standard
>>      tools would automatically support it, without depending on additional
>>      software installation for each new rich literal type.
>>
>>      Could N3 do this, given that it already has some executable rules
>>      capability?   Alternatively (or for improved performance), external
>>      library functions could be provided out-of-band.
>>
>>      David Booth
>>
>

Received on Monday, 27 July 2020 19:22:03 UTC