Why?

Currently, most stores require significant work to add new data-types. e.g. anything beyond the inbuild XSD types requires custom code. This makes it more difficult to use datatypes as a significant determinant of meaning.

This come up as part of a solution to issue #129

Previous work

Matching of arbitrary data-types in the earlier Specifications

Proposed solution

A RDF file that lists datatypes and can be read by stores.

unit:K rdfs:subClassOf xsd:decimal ;
  rdfs:label "Kelvin"@en ;
  rdfs:comment "SI Unit for temperature" .

A file such as this adds datatype definitions and allows the mathematical functions of xsd:decimal be called with this value (sameTerm("273.1"^^unit:K + "100"^^unit:K, "373.1"^^unit:K).

Allowing casts and additions xsd numerics allows for more convenient math operations in the queries.

{
 ?x ex:temperatureMeasurement ?tempInKelvin .
 FILTER(datatype(?tempInKelvin) = unit:K)

 # adding by xsd  numerics preserves type
 BIND(?tempInKelvin + 273.15) AS ?firstStepToCelsius)
 FILTER(datatype(?firstStepToCelsius) = unit:K)

 # adding by xsd  numerics preserves type
 BIND(xsd:decimal(?firstStepToCelsius) AS ?tempInCelsiusDecimal)
 FILTER(datatype(?tempInCelsiusDecimal) = xsd:decimal)

 # adding by xsd  numerics preserves type, cast from one datatype to another must be from
 # an xsd numeric. (Custom conversion functions are a different issue)
 BIND(unit:degC(tempInCelsiusDecimal) AS ?tempInDegreeCelsius)
 FILTER(datatype(?tempInDegreeCelsius) = unit:degC)
}

Some times, custom datatypes should extend xsd:string as appropriate.

iupac:DNA rdfs:subClassOf xsd:string ;
  rdfs:label "DNA"@en ;
  rdfs:comment "An representation of a DNA sequence in encoded in IUPAC spec" .

Considerations for backward compatibility

More data in the wild will be inconvenient to use in SPARQL 1.1. endpoints.