Re: Questions about value expansion

> On Nov 12, 2014, at 3:49 PM, Sean Johnson <belucid@acm.org> wrote:
> 
> In general, you should have a look at our test suite [1-2] which expresses all of this in a language-indented manner.. if you submit an implementation report, we'll include your conformance level in the official conformance report [3].
> 
> I plan to submit the report as soon as I finish the JSON-LD Processor conformance, before moving on to RDF.
> 
Great!

> "native boolean" => ["foo", true,
> …snip...
> 
> DateTime.parse("2011-12-27T10:11:12Z"), {"@value" =>
> "2011-12-27T10:11:12Z", "@type" => RDF::XSD.dateTime.to_s}],
> 
> Why does a native date, time and dateTime get expanded to include an
> @type, but a native integer does not?
> 
This isn’t for the spec, but handles some use cases when serializing RDF to JSON-LD using the RDF.rb Writer interface. The native formats aren’t canonical JSON-LD, but an artifact of the Ruby implementation. The only native types that are significant are Boolean, Integer, Float, Double, and nil.
> Honestly, I have no clue... and it's difficult to figure out what's going on here since you cite this without any context.
> 
> Fair enough. It would have presumably been the right amount of context for Gregg, but I can see how it would be a lot less meaningful to everyone else.
> 
Yes, also note that my implementation is something of an evolution from earlier times, and there are some things (particularly in context processing) that may be out-dated.
> When converting from or to RDF, types sometimes get added. See
> 
> http://www.w3.org/TR/json-ld-api/#data-round-tripping <http://www.w3.org/TR/json-ld-api/#data-round-tripping>
> OK… good to know. I do suspect some of what I'm seeing is code that's doing double duty for RDF which I haven't really looked at in the spec yet.
> 
> Value expansion is not one of those though :-)
> 
> OK. Great to hear as that was at the heart of my confusion. I seem to see types getting adding during value expansion in the Ruby implementation just based on their being a native type, rather than based on the context, and just wanted to make sure I didn't somehow miss that in the spec.
> 
> Similarly, I don't understand this value expansion behavior:
> 
> …snip…
> 
> Again, I don't know what's going on here and I don't have the time to dig into that. I would suggest to not try to reverse-engineer one of the existing implementations (that might do more than what's required) but really implement the algorithms as specified and run the official test suite.
> 
> 
+1, you’re probably getting more than you need from my implementation, but outside of Context processing, it should follow the spec pretty closely. Note that the Ruby API implementation doesn’t implement Futures, though, and is more Ruby-closure centric. This is arguable, and certainly doesn’t adhere to functional requirements, but works well with existing Ruby idioms.
> Thanks for the help! I'm just trying to ensure I do the right thing with
> value expansion and I'm confused by these differences in the spec and
> the Ruby implementation.
> 
> Then simply ignore the Ruby implementation :-) The spec is hopefully clear enough.. if not, let us know. Many more people will be able to help you with that than figuring out what a snippet of a specific implementation is doing (especially without context or links to the code).
> 
> Fair enough. I'll take that advice.
> 
> The approach I'd been taking is to implement to the spec, then compare my implementation to the Ruby one, not reverse engineering in any sense, but using it to confirm my understanding of the spec. It's been very helpful for the "sub algorithms" that need to be implemented before any of the official test suite will run (context processing, value expansion, iri expansion, etc.). But where I seem to see differences in how I understand the spec, my code, and the Ruby code, I'll just hold my questions until I get to the point of running the official test suite on my code.
> 
> 
I’m glad the Ruby implementation is useful for understanding how to implement it; it is open-source and in the public-domain, so you’re more than welcome to use any part that is useful. Ultimately, though, the JSON-LD test suite is the key thing to process. For a Clojure implementation, the main issue might be the need to order everything, which prevents some parallelism. However, for expanding and turning into RDF, you may be able to skip much of this and still get correct output.

Also, please don’t hesitate to contact me directly (but cc’ing the list is good). Otherwise, I may miss questions that I’m uniquely qualified to answer.

Gregg
> Cheers,
> Sean
>