TL;DR: I made something work that I have previously said is a bit wonk. I was wrong. Comprehensive round-tripping of linked data via HTML is possible.
One of the big bug-bears that I have had is that there’s no real way to do proper round-tripping of linked data in HTML; there have been a few attempts (we remember Fresnel) at doing things that make it possible, but it hasn’t really happened†.
And in comes JSON-LD, the JSON format for linked data. I can’t deny it, the silly way it was presented — those words irritated me — made me think “nonsense”. We already had RDF/JSON and it worked. Well, it worked for the few who actually understand RDF. But, it didn’t work well for people un-used to RDF and it only had support in the application as long as you put it there.
When using JSON-LD, I have had little control over serialisation — I’m used to RDF just working, but producing “pretty” JSON-LD (i.e. the kind of thing that doesn’t make your ears bleed when you’re trying to parse a document) seemed nigh-on impossible. I have always known what the problem was: my not understanding, nor having tools that worked with framing.
With a few small hints from Markus Lanthaler (who does more good for JSON-LD-take-up than any other person involved), I finally got it to work. JSON-LD Java has good support for framing and after a bit of tweaking in the JSON-LD playground, my data was ready to fly.
This all sounds like delight and mirth (as a bad Norwegian translator might have it), but let’s analyse what I was doing: putting linked resources into arrays. I also wanted a heavy context object that got rid of any silly namespace nonsense (and alias JSON-LD “@” artefacts). I also wanted to suppress “@id” inside the object as well as banish “@graph”. Actually, what I wanted was simple, recognisable JSON. And that is what I now have with the help of JSON-LD, framing and Gson (I have to chew the JSON-LD a bit because framing doesn’t support suppression of objects).
What this has bought is control. JSON objects can now be produced that can be consumed by simple JSON-oriented services (like an indexes or parsers). It has become apparent to me that lightweight, focussed data structures are necessary outside the comfort of in-memory objects. Sometimes what is simple and lightweight has surprised me (like finding the simple, generic format that will allow multi-linguality to slip through the parser un-challenged didn’t involve enumerating languages as keys…), while yet other times I was thoroughly un-surprised that common data-modelling from RDBMSes works really well.
The upshot of all this is that the JSON that is created works well because it is more JSON and less LD. Now, you’d find that a shame if you were then the kind of person who was trying to round-trip this data via HTML. And it is here that I can relate a minor epiphany: you don’t need to use the same data structure in as is used out. In fact, there are really good reasons why you ought not to‡.
The HTTP-PATCH format being used to generate plain-old RDF works well and continues to surprise — it turned out that it does indeed support blank nodes (with a minor tweak) and all is delight and mirth (again). Combined with now-easier-to-work-with JSON for consumption, I’m pretty sure that the elusive round-trip is in place.
† Feel free to disagree that this is untrue; I know a lot of folk have XML-workflows that work, but these don’t rock my boat.
‡ I ought to write about this in another piece.