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

Note that I rely on the java-ucum implementation, and there are of course
some limitations for corner cases such as the one you point..

augmenting your example and testing it at
https://ci.mines-stetienne.fr/lindt/playground.html,

select * where {
  ?x :angle ?y .
  filter ( ?y >= "1 rad"^^cdt:angle )
  bind( "0 deg"^^cdt:angle + ?y AS ?z)
}

I find that ?z = "57.29577951308232 deg"^^cdt:dimensionless in all cases.

The specific location for value equality testing in my implementation si
here:
https://github.com/apache/jena/compare/master...OpenSensingCity:jena-3.6.0-ucum#diff-f12519aa2b38637a2ec7758ed684fc80R572


as you can see,
q1.getValue().floatValue() probably approximates the value.

Comparison is here
https://github.com/apache/jena/compare/master...OpenSensingCity:jena-3.6.0-ucum#diff-f12519aa2b38637a2ec7758ed684fc80R896


Addition etc start here
https://github.com/apache/jena/compare/master...OpenSensingCity:jena-3.6.0-ucum#diff-1de32f58ef7669c2104d8fa5e0c00ce9R171


Best regards,
Maxime Lefrançois
MINES Saint-Étienne
http://maxime-lefrancois.info/


Le lun. 27 juil. 2020 à 19:40, Peter F. Patel-Schneider <
pfpschneider@gmail.com> 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
> >
>
>