RE: JSON-LD Telecon Minutes for 2013-05-14 / RDF-ISSUE-128 and RDF-ISSUE-129

On Sunday, May 19, 2013 10:21 PM, Gregg Kellogg wrote:
> > You don't eliminate it, you just move it somewhere else.
> 
> The point is that for transport issues, such as getting a JSON-LD
> representation of an RDF dataset, we retain full fidelity. To do that
> now, would require that the _use native types_ flag be set as an type
> parameter in the HTTP header, something we don't provide for AFAIKR. By

Just define a profile and use that if you need to.


> having transport format use string representations of literals, we
> don't incur any data loss.

We don't lose any information if we transport it as JSON-LD either. The
information is lost if the JSON-LD on the wire contains numbers outside of
the value range of the JSON parser. To say it again, this is not a problem
of JSON-LD.. the problem is how current parsers work. Till now, that has
proven to not cause major problems otherwise parsers would have been
changed.


> The idea behind putting it in the Expansion algorithm is to defer any
> data-loss to the end application which chooses to work with the data
> using native JSON values. Then it becomes a chose of the consuming
> application, rather than an assumption of the providing service which
> is serializing RDF as JSON-LD.

I honestly don't understand the distinction you are making between producer
and consumer. There's nothing there defining the fromRDF algorithm as a
producer-algorithm and the compaction/expansion algorithms as
consumer-algorithms. I don't believe that publishers would want to create
JSON-LD that doesn't look native. I actually think the contrary is the case.
By shifting the complexity to expansion we make both the JSON-LD users' and
the RDF2JSON-LD users' life more difficult. A JSON-LD user now has to think
about flags which he otherwise wouldn't have to. A RDF2JSON-LD user now not
only has to convert it to JSON-LD, but she also needs to re-expand/compact
the result it to finally get native numbers - I'm convinced that most
publishers want to publish native numbers.


> If the client were taking another RDF representation and converting to
> JSON-LD, then sure. In any case, the client could string together a
> series of transformations to get what they want. I'm presuming that a
> JSON-LD client performs content negotiation with a servce to get what
> they want. If they prefer JSON-LD, they may get that and then transform
> to native types if so desired.

And what if the data doesn't come from an RDF source but an ordinary DB?
Would that then as well have to be transferred using literals? If not,
what's the point of doing so in the case where the original source was a RDF
document? Does a client have to care? I would say no. If the publisher
thinks native types may be problematic it can use literals.


> > As it currently stands, I would -1 the proposal to move the
> transformation
> > to expansion/compaction.
> 
> Did you listen to where this was discussed on the telecon? I think that
> imposing data-loss by default is a problem, and allowing the client to
> perform this operation makes sense to me, rather than have it imposed

Yes, I did. If the data-loss we are talking about here matters, the
publisher can use literals. Again, this hasn't been a problem in JSON so
far. Why should it be in JSON-LD?


> on them. If you really do object to this, then to satisfy Sandro's
> concern, perhaps the thing to do is to change the default for _use
> native types_ to false, and add it as a mime parameter.

Sandro and I already had agreement on this:

<snip>
Markus and I have consensus on a way forward:

- for useNativeTypes=True, all numeric types (except xsd:decimal) are 
converted to json native numbers.  on translation back to RDF literals, 
they'll all end up as xsd:double.
- we'll say clearly that setting useNativeTypes=True MAY change the 
value and/or datatype of any RDF numeric literals (except xsd:decimal).  
So keep it False if you want exact roundtrip conversion.

That seems like the best path forward.
</snip>

http://lists.w3.org/Archives/Public/public-rdf-wg/2013May/0152.html



> Perhaps we should defer a resolution on this matter until you can join
> the telecon, presumably next week?

I'll be on the plane back home next week



--
Markus Lanthaler
@markuslanthaler

Received on Monday, 20 May 2013 01:55:03 UTC