Re: Controlling datatypes

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).
>
+1


> 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
>
> "1.3.5.1 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 ;-)

Cheers,
Christophe


-- 
Dr. Christophe Guéret (christophe.gueret@dans.knaw.nl)
http://www.few.vu.nl/~cgueret/
http://semweb4u.wordpress.com/
Postdoctoral researcher working on CEDAR (http://cedar-project.nl/)
Royal Netherlands Academy of Arts and Sciences
Data Archiving and Networked Services (DANS)