Re: Use of XSD namespace in RDF recommendations

On 4 Sep 2012, at 22:18, Gregg Kellogg wrote:
>> I guess I like the idea of informatively linking to both the 2006 SWBP Note on datatypes [1] and to the OWL 2 datatype definition mechanism [2], stating that both XML Schema and OWL 2 provide facilities for formally defining RDF datatypes, but that support for neither mechanism is required for RDF.
> 
> Perhaps I'm missing something, but

We are talking about formally defining custom datatypes. If you want an ex:HexRGBColor datatatype, how do you define or describe the datatype?

> it seems that RDF Concepts does have a normative relationship to XSD,

Of course.

> as literals with no datatype IRI or language tag get the datatype xsd:string.

Well, in RDF 1.1 Concepts, there is no such thing as a literal without a datatype IRI.

[[
Concrete syntaxes may support simple literals, consisting of only a lexical form without any datatype IRI or language tag. Simple literals only exist in concrete syntaxes, and are treated as syntactic sugar for abstract syntax literals with the datatype IRI http://www.w3.org/2001/XMLSchema#string
]]
http://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal

> Also, in Turtle, native number representations are associated with xsd:integer, xsd:decimal and xsd:double.
> 
> true/false values are represented as literals with xsd:boolean.

Right.

> We considered this in JSON-LD; JSON numbers are translated to xsd:integer or xsd:double, and true/false to xsd:boolean when transforming to RDF.

Doing this differently from SPARQL in the case of xsd:decimal (that is, fraction but no exponent) is a bad idea. You'll get situations where 1.0 in a SPARQL query doesn't match 1.0 in a JSON-LD document because of different numeric datatypes, and where 1.0 written in Turtle and 1.0 written in JSON-LD produce different literals.

> When going from RDF, strings are used unless an option is specified do use xsd types.

That doesn't quite make sense to me.

xsd:string strings should always be JSON strings and never XSD types in JSON-LD.

The xsd:integer, xsd:decimal, xsd:double and xsd:boolean types should always be represented with the native JSON number / boolean representation, and never as XSD types.

For the other types (rdf:XMLLiteral, rdf:HTML, rdf:langString, xsd:xxx, any custom data types) I would argue quite strongly that the default should be to retain all information (hence allowing round-trips from RDF to JSON-LD back to RDF). Perhaps there could be a switch that, if manually enabled, serializes all these literals as plain strings.

But my preferred option would still be that toRDF can be invoked with a context object, and if I want some property with a custom datatype to be serialized as a simple JSON string, then I can provide a term definition with type coercion for that property in the context object. I'm not sure if the JSON-LD APIs support something like this at the moment.

Best,
Richard

Received on Tuesday, 4 September 2012 21:55:53 UTC