Re: Resolutions for features at risk [JSON-LD]

Gregg Kellogg
gregg@greggkellogg.net

On Jun 1, 2013, at 3:55 AM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> On Saturday, June 01, 2013 5:28 AM, Gregg Kellogg wrote:
>>>> I think this needs more discussion. I would be a -1 on anything that
>>>> yields a non-round-tripable RDF/JSON-LD/RDF conversion.
>>> 
>>> We have that already, useNativeTypes = false
>> 
>> If that were the default, then I'd probably be okay with it, but the
>> default is true, which leads to data loss.
> 
> Then the simplest thing to do is probably to set it to false. In that case
> however we should add some mechanism that allows to convert expanded value
> objects to be converted to native types. Compaction would be the best place
> to do so IMO.
> 
> That being said, I still believe a data publisher is capable of deciding
> whether such a data loss is acceptable or not and set the flag accordingly
> when converting RDF to JSON-LD.
> 
> 
>>> Could you please describe how you would see this work. E.g., how
>>> would the
>>> following JSON-LD snippets be expanded/compacted/converted to RDF:
>>> 
>>> "prop1": { "@value": 5 }
>> 
>> Given that it's starting as a native value, it could either be
>> interpreted as "5"^^xsd:integer or "5.0E0"^^xsd:double. We currently
>> say the former, but I could see always transforming native JSON numbers
>> to xsd:double.
> 
> Thanks Gregg. What I was looking for however was something looking more like
> a test case. Something like
> 
> useNativeTypes = true, expressed as (1) in the following statement
> 
>  "prop1" --expand(1)--> { "@value": 5 } --compact(1)--> "{ "@value": 5 }
> 
> and if useNativeTypes = false, expressed as (0) in the following statement
> 
>  "prop1" --expand(0)--> { "@value": "5" } --compact(0)--> "{ "@value": "5"
> }
> 
> because I'm not sure I completely understood your proposal in all its
> details. 
> 
> So here are the JSON-LD snippets to be expanded/compacted/converted to RDF
> again:
> 
>  "prop1": { "@value": 5 }
>  "prop2": { "@value": 5, "@type": "xsd:double" }
>  "prop3": { "@value": "5.0", "@type": "xsd:double" }
>  "prop4": { "@value": "5.0E0", "@type": "xsd:double" }
>  "prop5": { "@value": "99999...1000s.of.9s", "@type": "xsd:integer" }

Okay, for expansion/compaction, I think there are really three states: useNativeTypes=true, useNativeTypes=false and not specified. In the case that the option is not specified, it should just be the existing behavior. If useNativeTypes is true, it should convert all xsd numeric types (at least xsd:boolean, xsd:integer, xsd:decimal, and xsd:float, but probably all their sub-types as well) to a native JSON representation. If set to false, it should convert all native types to expanded values using a string representation, probably converting all numbers to xsd:double. Here's some possible test results:

useNativeTypes=false with expand:

  "http://example/prop1": [{"@value": "5.0E0", "@type": "http://www.w3.org/2001/XMLSchema#double"}],
  "http://example/prop2": [{"@value": "5.0E0", "@type": "http://www.w3.org/2001/XMLSchema#double"}],
  "http://example/prop3": [{"@value": "5.0", "@type": "http://www.w3.org/2001/XMLSchema#double"}],
  "http://example/prop4": [{"@value": "5.0E0", "@type": "http://www.w3.org/2001/XMLSchema#double"}],
  "http://example/prop5": [{"@value":  "99999...1000s.of.9s", "@type": "http://www.w3.org/2001/XMLSchema#integer"}],

useNativeTypes=true with expand:

  "http://example/prop1": [{"@value": 5}],
  "http://example/prop2": [{"@value": 5, "@type": "http://www.w3.org/2001/XMLSchema#double"}],
  "http://example/prop3": [{"@value": 5, "@type": "http://www.w3.org/2001/XMLSchema#double"}],
  "http://example/prop4": [{"@value": 5, "@type": "http://www.w3.org/2001/XMLSchema#double"}],
  "http://example/prop5": [{"@value":  4611686018427387903, "@type": "http://www.w3.org/2001/XMLSchema#integer"}],

The last one really can't be specified, due to the fact that JSON doesn't specify it. I used 2^62-1, but we probably shouldn't even test it.

For compaction, I presume that the intention of someone using this would be to reduce such values to a simple value, not a expanded value if useNativeTypes is set to true. I also presume that none of the properties have a type coercion applied

useNativeTypes=false with compact: 

 "prop1": { "@value": "5.0E0", "@type": "xsd:double" }
 "prop2": { "@value": "5.0E0", "@type": "xsd:double" }
 "prop3": { "@value": "5.0", "@type": "xsd:double" }
 "prop4": { "@value": "5.0E0", "@type": "xsd:double" }
 "prop5": { "@value": "99999...1000s.of.9s", "@type": "xsd:integer" }

useNativeTypes=true with compact:

 "prop1": 5
 "prop2": 5
 "prop3": 5
 "prop4": 5
 "prop5": 4611686018427387903

(same caveat on prop5)

> and how the corresponding RDF literals would be transformed to JSON-LD:
> 
>  <> <prop3> "5"^^"xsd:double" .
>  <> <prop3> "5.0"^^"xsd:double" .
>  <> <prop4> "5.0E0"^^"xsd:double" .
>  <> <prop5> "99999...1000s.of.9s"^^"xsd:integer" .

  "http://example/prop2": [{"@value": "5", "@type": "http://www.w3.org/2001/XMLSchema#double"}],
  "http://example/prop3": [{"@value": "5.0", "@type": "http://www.w3.org/2001/XMLSchema#double"}],
  "http://example/prop4": [{"@value": "5.0E0", "@type": "http://www.w3.org/2001/XMLSchema#double"}],
  "http://example/prop5": [{"@value":  "99999...1000s.of.9s", "@type": "http://www.w3.org/2001/XMLSchema#integer"}],

Gregg

> Thanks,
> Markus
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
> 
> 
>

Received on Sunday, 2 June 2013 19:53:21 UTC