Re: Controlling datatypes

On 21/09/12 08:25, Christophe Guéret wrote:
> Hi Andy,
>
> On 20 September 2012 15:44, Andy Seaborne <andy.seaborne@epimorphics.com
> <mailto: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.

Two questions for you:

1/ What about the geospatial geometry example?

2/ Such data exists and will exist.  Just because you/we don't think it 
is modelled right, do we prohibit from LDP?

 Andy

>
> 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
> <mailto: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)
>
>

Received on Friday, 21 September 2012 08:15:09 UTC