- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 25 May 2011 22:57:06 -0400
- To: Linked JSON <public-linked-json@w3.org>
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? 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. 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? > 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. -- 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/
Received on Thursday, 26 May 2011 02:57:44 UTC