- From: Nicolas Chauvat <nicolas.chauvat@logilab.fr>
- Date: Sat, 1 Oct 2022 19:40:43 +0200
- To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
- Cc: Martynas Jusevicius <martynas@atomgraph.com>, semantic-web@w3.org
Le Sat, Oct 01, 2022 at 09:52:06AM -0400, Peter F. Patel-Schneider a écrit :
> Along these lines, I wrote a long message describing several ways of
> representing information in RDF graphs. This response nicely illustrates
> one of the points I am trying to make so I'm using it as, perhaps, a TL;DR
> for my message.
Thank you for this long explanation.
I understand you are saying we have to chose between:
:marty :driveTo [ a :TZDateTime, :date "1985-10-26", :time "09:00", :tz "EST" ] .
and
:marty :driveTo "1985-10-26 09:00 EST"^^:TZDateTime
but should not long for something like
:marty :driveTo ("1985-10-26", "09:00", "EST")^^:TZDateTime
because if it has a structure, this structure is expected to be
described using a class or a datatype.
Am I following you correctly ?
But does not the TZDateTime datatype imply that the string has a structure ?
When I will read "e1"^^:ChessPosition I will need to split the string
in two if I want to access the rank and the file separately.
> A disadvantage of the datatype route is that a particular RDF system
> mignt not implement the chess:position datatype.
What does it mean for a RDF system to "implement" the chess:position datatype ?
PS: I can live with defining classes or (de)serializers for every
value I want to share using RDF, I am just trying to understand what
are the design decisions that led to this situation and I wonder if
these specificities of the RDF model are not hurdles to a wide adoption
by the crowd of developers.
--
Nicolas Chauvat
logilab.fr - services en informatique scientifique et gestion de connaissances
Received on Saturday, 1 October 2022 17:40:55 UTC