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

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