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

The second part of my previous mail addressed this point, but I believe it
flew under the radars. Let me reformulate
https://lists.w3.org/Archives/Public/semantic-web/2020Jul/0170.html

In the same vein as cdt:ucum and the sub-datatypes, we could consider that
other datatypes could be defined to conveniently represent other
engineering-related data, such as complex numbers, complex numbers + unit,
geocoordinates, lists, sets, matrices, RGB colours, ... each having its own
Lexical Space, Value Space, Lexical-to-Value mapping, ...

By the way, the relation "sub-datatype" is underspecified.  one datatype
could have a sub-lexical space and/or sub-value space, and/or sub-L2V, of
another one.

There already are some datatypes that encode big structures, and are
already standards.
I am thinking about rdf:XMLLiteral,  rdf:HTML.

For these, I would have preferred a solution with IANA IRIs, as most of
them dereference, for example:
   https://www.iana.org/assignments/media-types/application/xml
   https://www.iana.org/assignments/media-types/text/html
   https://www.iana.org/assignments/media-types/application/json

If we imagine datatypes that encode RDF graphs,
The Lexical Space would be defined in terms of RDF serialization formats
The Value Space would be defined in terms of the entailment regime, as the
definitions of equality would depend on it

If we head in this direction, I imagine that the natural "unpacked"
representation as RDF could have something to do just with named graphs in
named graphs or dereferencing ..

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


Le ven. 24 juil. 2020 à 21:55, Shaw, Ryan <ryanshaw@unc.edu> a écrit :

>
> > On Jul 24, 2020, at 2:43 PM, Hugh Glaser <hugh@glasers.org> wrote:
> >
> > Also, what about other literals?
> > Presumably, by implying the same approach and implementation structure,
> we can have:
> > Literals for telephone numbers (ITU compliant),
> > ISO 19160 or whatever it is for addresses.
> > Librarians would presumably like a structured literal for peoples names.
> > Can I have a similar process for URIs as literals, perhaps.
>
> These all strike me as great and useful ideas.
>
> What if it were easy to create new datatypes that mapped between 1) DSLs
> for producing structured string literals (see examples above) and 2)
> "unpacked" representations as RDF?
>
> That would also be useful for stuff like:
>
> * common bibliographic citation patterns as documented in CSL styles
> * Extended Date and Time Format
> * GeoJSON
> * IP addresses
> * all kinds of printed product codes
>
> - Ryan
>

Received on Monday, 27 July 2020 16:52:32 UTC