Re: JSON-LD test suite repository

On May 25, 2011, at 19:58, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 05/24/2011 06:57 PM, Gregg Kellogg wrote:
>> I've ported the RDFa test suite [1] repo for the JSON-LD test-suite [2],
>> and added a number of tests that I've used for my parser [3]. 
> 
> Gregg, this is fantastic work! Thank you so much for moving that stuff
> over!
> 
> I've been thinking a bit more about what Kingsley said and whether or
> not we should put a focus on RDF or put a focus on Linked Data. The
> conversation over the past week on this mailing list seemed to indicate
> that many felt wary about moving away from RDF - but some did see a
> benefit in moving RDF into the background. That is, Linked JSON should
> still be able to be converted to RDF - but perhaps we should try and
> avoid pulling in the entire RDF/SPARQL/NTriples stack?

I suppose the JSON-LD might serialize to something that's not RDF, but I think it will probably need to have a graph representation, so some form of triples will probably be necessary. For example, we could decide that a literal could be used as a subject. Are there some examples of linked data that might not serialize to triples?

> Applying this to the test suite - it seemed that we could test for
> JSON-LD parser interoperability by migrating all data into JSON-LD
> normalized form. That is, for all of the transformation that is
> performed - as long as the normalized form matches, we can be fairly
> certain that the RDF will be the same across JSON-LD processors. In
> other words, a string compare between two normalized JSON-LD processor
> outputs will tell us whether or not the processors are generating graphs
> that are inter-operable.

Well, there are a couple of issues here: normalized JSON-LD can't represent named BNodes, and multiple-valued properties could be serialized, but not represented properly. Serializing to N-Triples might solve this, but BNode equivalence can be challenging; still, this is done for other  serializations such as N3, which is also an RDF super-set.

> We could then declare the RDF translation as operating on the normalized
> form of the data - which would make the translation algorithm much
> simpler since the processor wouldn't have to do any CURIE expansion or
> datatype conversion. So, while I was thinking of this, Dave Longley has
> also been working on a series of tests for Monarch (our high-performance
> web server) with a JSON-LD in C++.
> 
> https://github.com/digitalbazaar/monarch/blob/13e3d1f937afdb90533c688722005001fa77a783/cpp/tests/test-jsonld.cpp
> 
> Turns out that he tested the Monarch JSON-LD processor by doing just
> that - checking against the normalized output, instead of outputting to
> RDF/XML and performing a SPARQL query on the graph.
> 
> This seems like it would be simpler to implement and easier to test
> against for JSON-LD processor writers. No complicated RDF/XML and SPARQL
> required. We could still test the JSON-LD to RDF/XML/SPARQL conversion
> capability of the JSON-LD processors, but that would be a separate part
> of the test suite. Perhaps even making RDF conversion an optional
> capability of JSON-LD processors?

 It's certainly simpler, and more accessible to not use SPARQL. But there may be some advantages to N-Triples.

>> I made
>> some blind changes to the Python and JavaScript bits, but it must be
>> validated and hosted, provisionally at http://json-ld.org/test-suite/.
> 
> I'll fix that stuff up when I get a free moment... don't know when
> that'll be... it may take a while since I have a good backlog of RDFa
> work to do.
> 
>> There is plenty of room for negative test cases and more corner-cases.
>> The repo is owned by the json-ld organization, and either Manu or I can
>> add anyone else that would like full access. Or the clone/pull workflow
>> can also be used, but please work on a separate branch to make merging
>> easier.
> 
> I think we should integrate the test suite with the json-ld.org website
> - what do you think? Keep it all together. I could migrate the
> json-ld.org website over to the json-ld organization soon, or pull your
> changes into the json-ld.org website and then migrate the whole thing
> over. If you get a free minute or two - ping me on Skype so we can
> discuss the details.

It should definitely be integrated somehow; not having to do SPARQL can make it much easier. It would be great to do a simple string compare, but we'd need to specify BNode representation I N-Triples if we were to use this. Comparing with normalized JSON-LD would be easier, except for the named BNodes part. If we were to address this in the spec, that could solve the problem.

> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: PaySwarm Developer Tools and Demo Released
> http://digitalbazaar.com/2011/05/05/payswarm-sandbox/
> 

Gregg

Received on Thursday, 26 May 2011 07:07:42 UTC