W3C home > Mailing lists > Public > public-linked-json@w3.org > May 2011

Re: JSON-LD test suite repository

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Wed, 25 May 2011 22:57:06 -0400
Message-ID: <4DDDC182.7000403@digitalbazaar.com>
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

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++.


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
Received on Thursday, 26 May 2011 02:57:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:53:17 UTC