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

On May 31, 2013, at 5:26 PM, Markus Lanthaler <markus.lanthaler@gmx.net> wrote:

> On Saturday, June 01, 2013 2:04 AM, Gregg Kellogg wrote:
>> I've had more discussions with Danbri, and I think we may make more
>> progress this week at SemTech, with several people from Google, the
>> other schema.org partners, Sandro and myself there all in person. In
>> particular, there's a Semantic Hack day tomorrow where we may have some
>> time to dive into this more.
>> 
>> At this point, I'm not too concerned about not having a context at
>> http://schema.org/. Certainly, what you have is the absolute minimal,
>> but we can probably do better than that.
> 
> Great! Let me know if I can help somehow.
> 
> 
>>>> PROPOSAL: Allow blank nodes to be used as graph names or properties
>>>> in JSON-LD 1.0.
>>> 
>>> I'd suggest holding off on this until after rdf-concepts has gone to
>> last call.
>> 
>> There's no point in resolving anything while the issue is still being
>> tossed around for RDF Concepts; ideally, the general use of BNodes as
>> graph labels will prevail, and this becomes a non-issue.
> 
> JSON-LD could still be a super-set of RDF. Even if bnodes would be allowed
> for graph names, we would still have to decide what to do with predicates.
> 
> 
>>> I like Gregg's idea that the conversion be done separate from RDF
>> conversion.  That way the conversion can, in general, be done just in
>> the consumer, where the actual platform characteristics are known and
>> errors can be thrown if necessary.
>>> 
>>> One COULD do that conversion before sending out some JSON-LD on the
>> wire, but we should warn that will lead altered values of certain
>> numbers when going between certain pairs of platforms.
>> 
>> I think this needs more discussion. I would be a -1 on anything that
>> yields a non-round-tripable RDF/JSON-LD/RDF conversion. I know Sandro
> 
> 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.

>> said he couldn't be on Tuesday's call due to SemTech, but given that
>> it's at 7:00PST out here, perhaps he can make it after all. I think it
>> bears discussion.
> 
> Definitely
> 
> 
>> As Sandro said, from my perspective, allowing the client to perform
>> these convesions as part of normal transformations makes sense to me,
>> rather than over-relying on JSON native types, and certainly not when
>> there's loss of fidelity.
> 
> It certainly makes sense to allow a client to perform these conversions but
> you can't prevent that people will create JSON-LD with native types in it
> which are outside the 32/64 bit range.
> 
> 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.

>  "prop2": { "@value": 5, "@type": "xsd:double" }

Could be either "5"^^xsd:double or "5.0E0"^^xsd:double, I believe we specify the former.

>  "prop3": { "@value": "5.0", "@type": "xsd:double" }

The meaning is clearly "5.0"^^xsd:double.

>  "prop4": { "@value": "5.0E0", "@type": "xsd:double" }

The meaning is clearly "5.0E0"^^xsd:double.

>   "prop5": { "@value": "99999...1000s.of.9s", "@type": "xsd:integer" }

According to XSD, the value space of xsd:integer is a finite-length sequence of decimal digits with an optional leading sign, thus this has a clear equivalent representation.

With all the above, transforming to a JSON native value will incur loss depending on the implementation, until/unless the JSON spec provides some normative requirements on number representation.

> 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" .
> 
> with the flag(s) set to true/false.

I think these are all clear with the flag set to false, being exactly the same string and datatype representation. With the flag set to two, it is the result of parsing the string to JSON, which depends on the precision of the underlying implementation. The first three are all the same value of 5, and any lexical distinction is lost to the native transformation. This is why I suggest that, as a line protocol, not relying on native JSON types when transforming from an abstract RDF representation to JSON-LD ensure that a reverse transformation will not loose information. Since a service can't really know how a client will use the data, it's better to not make such decisions there (e.g., when performing content negotiation on an RDF store). The client can choose to represent numbers in a native representation through an algorithmic transformation if that is more convenient to work with.

Gregg

> Cheers,
> Markus
> 
> 
> --
> Markus Lanthaler
> @markuslanthaler
> 
>

Received on Saturday, 1 June 2013 03:28:16 UTC