W3C home > Mailing lists > Public > public-rdf-comments@w3.org > September 2012

RE: XSD datatypes in JSON-LD (was: Re: Use of XSD namespace in RDF recommendations)

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Wed, 5 Sep 2012 11:38:15 +0200
To: "'Richard Cyganiak'" <richard@cyganiak.de>, "'Gregg Kellogg'" <gregg@greggkellogg.net>
Cc: "'public-rdf-comments Comments'" <public-rdf-comments@w3.org>
Message-ID: <00df01cd8b4a$2dc469a0$894d3ce0$@lanthaler@gmx.net>
Hi Richard,

I think I can answer these questions as well. Let me try.

> > We did discuss always using the native representations for
> xsd:integer and xsd:double, but this was deemed to introduce too much
> chance of data corruption. See "Data Round Tripping in the API[1] and
> discussion in issues 98 [2] and 81 [3].
> You lost me here. Where and how are non-native representations of
> xsd:integer and xsd:double used?

If you have the following somewhere in your JSON-LD document

"ex:prop": 5

it will get expanded to

"http://example.com/prop": [ { "@value": 5 } ]

which means it is still a native representation. Only if you do a toRDF()
call it will be transformed to

_:something <http://example.com/prop> "5"^^xsd:integer

On the other hand you can express typed values like so:

  "@context": {
    "prop":  {
      "@id": "http://example.com/prop",
      "@type": "http://www.w3.org/2001/XMLSchema#decimal"
  "prop": "5.0"

This will get expanded to

"http://example.com/prop": [ {
   "@value": 5,
   "@type": "http://www.w3.org/2001/XMLSchema#decimal"
 } ]

> > However, within the JSON-LD API methods, there is no way to convert
> from native types to expanded (or string compacted) values without
> going through RDF and using the "useNativeTypes" flag.
> Lost me again.

I think what Gregg meant was that there's no way *within* JSON-LD to expand
"prop": 5 to "prop": { "@value": "5", "@type": "xsd:integer" } without first
doing a toRDF() conversion and then converting fromRDF() with the
"useNativeTypes" flag [1] set to false (which means that no JSON-native
types should be used but the expanded form should be maintained.

> What is a string-compacted value?

I think what Gregg meant with this term is, e.g., having "prop" coerced to
"xsd:integer" in the context and having "prop": "5" in the body.

> Is there a test case or example that shows the difference between
> enabled and disabled useNativeTypes?

No, currently we do not have any tests using the various API flags.

> useNativeTypes defaults to true, right?


> Why would one want to set useNativeTypes to false?

E.g. to not lose the information that 5 was intended to be a double when
converting "5"^^xsd:double to JSON-LD. Otherwise "5" would be converted to a
native JSON number and in the next toRDF() call it would become
"5"^^xsd:integer as there's no fraction.


Markus Lanthaler
Received on Wednesday, 5 September 2012 09:38:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:54 UTC