W3C home > Mailing lists > Public > public-ldp-wg@w3.org > September 2012

Re: Controlling datatypes

From: Christophe Guéret <c.d.m.gueret@vu.nl>
Date: Fri, 21 Sep 2012 09:25:48 +0200
Message-ID: <CABP9CAG8Xmk2C=zYmDQt5bpY-+voyEy73MPHsNvEXBRWmTAwJw@mail.gmail.com>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Hi Andy,

On 20 September 2012 15:44, Andy Seaborne <andy.seaborne@epimorphics.com>wrote:

> I don't have a clear articulation of the problem in my mind yet so I
> haven't raised an issue for this.
> [[
> 4.1.9 BPR representations MUST use only the following standard
> datatypes. RDF does not by itself define datatypes to be used for
> literal property values, therefore a set of standard datatypes based on
> [XSD Datatypes] and [RDF] are to be used:
> ]]
> It's a good thing to suggest to applications writers (data producers)
> that sticking to a core set of datatypes can be a benefit
> interoperablity of data.  There is a steady stream of questions on
> forums and mailing lists which show that spurious datatyping, and
> unnecessary language tags, confuse app writers (data consumers).

> But a consequence of the current wording is that some data can not be
> used with LDP.
> Example 1 -- OGC [1], define a geospatial RDF schema that includes
> " RDFS Datatype: ogc:WKTLiteral" [2]
> and the example given is
> "<http://www.opengis.net/def/crs/OGC/1.3/CRS84>
> Point(-83.38 33.95)"^^ogc:WKTLiteral
> which is an RDF datatype not in the list of BP 4.1.9.
> Example 2 -- QUDT [3] defines a datatype for degrees Kelvin.
>    http://www.qudt.org/qudt/owl/1.0.0/unit/Instances.html#Kelvin
> It has a knock-on effect.  If some vocabulary you want to use defines
> the range of a property using a datatype not in the list (it can be as
> simple as xsd:int or xsd:gYear) the vocabulary itself is effectively
> off-limits.
> What is the right balance here?
I would argue here that these two new data type definitions are a modeling
choice that could have been done differently.
IMHO, the datatype of a literal is just an indication of its serialisation,
not its meaning. That is, creating a data type for degree Kelvin is saying
that the number is both an xsd:float and that it represents a measure whose
unit are Kelvins. There are other ways to model this, without introducing
new data types. The same applies for xsd:gYear.

One other example: if we allow for custom data type, would <X,
voc:hasPopulation, 5000^^voc:Population> something that makes sense?
I don't think so ;-)


Dr. Christophe Guéret (christophe.gueret@dans.knaw.nl)
Postdoctoral researcher working on CEDAR (http://cedar-project.nl/)
Royal Netherlands Academy of Arts and Sciences
Data Archiving and Networked Services (DANS)
Received on Friday, 21 September 2012 07:26:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:31 UTC