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

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 17:36:50 UTC