You know from a previous blog post that I have really been enjoying using RDF/JSON. The reason I like it is not because of the wire format, but because it allows me to think of an RDF graph as a simple programming data structure - basically a dictionary of dictionaries of values. It demystifies RDF - I don't need special libraries to deal with it. Also, RDF/JSON is about the simplest spec I've ever seen - if you agnore a little boilerplate, the whole spec fits on a single page of my screen. Even with boilerplate, it's only about 3 pages.
I did run into one issue though. In RDF, there are two ways that a property can be multi-valued. One is that there is a single triple whose value is a List, and the other is that there are multiple triples with the same subject and predicate. These two things have subtly different meaning, with perhaps the most obvious and commonly understood difference being that one is ordered and the other isn't. Representation languages like Turtle have two forms to distinguish between them, for example:
<John> <loves> (<Mary> <Jane> <Sally>) versus <John> <loves> <Mary>, <Jane>, <Sally>
RDF/JSON only has one representation and the spec makes it very clear that the second case - the unordered one - will show up in JSON as an array (which is ordered, of course). There is nothing in the spec to tell you how the first case should show up in RDF/JSON, but it;s pretty clear you have a Hobson's choice (two equally unpleasant possibilities). One possibility is that the first case and the second case both produce the same RDF/JSON. This has the advantage that the first case shows up in a form that is reasonable for programmers to deal with (remember that is why we love RDF/JSON in the first place). The disadvantage is that I can no longer tell the difference between the first and second cases. The other possibility is that in RDF/JSON, you have to spell out the RDF List "the long way". This would seem more "correct", but RDF lists are horrible structures to deal with in a program - you really want them in the native List/Array format of your programming language.
I don't really have a good solution to this - if I've missed anything obvious, or you can think of something clever, let me know. What we are doing right now is producing an Array in both cases, and requiring the client to know - for example by the predicate - which was really intended.