- From: Maxime Lefrançois <maxime.lefrancois@emse.fr>
- Date: Mon, 27 Jul 2020 18:52:04 +0200
- To: "Shaw, Ryan" <ryanshaw@unc.edu>
- Cc: Hugh Glaser <hugh@glasers.org>, Antoine Zimmermann <antoine.zimmermann@emse.fr>, Semantic Web <semantic-web@w3.org>
- Message-ID: <CALsPASWdEy-AnfzX7=3xT-6=ha4XYxGFOZCubBwahG-pz+Xo5Q@mail.gmail.com>
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