W3C home > Mailing lists > Public > public-rdf-comments@w3.org > April 2013

RE: RDF/JSON

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Mon, 29 Apr 2013 12:25:38 +0200
To: "'Martin Nally'" <martin.nally@gmail.com>
Cc: <public-rdf-comments@w3.org>
Message-ID: <00a101ce44c3$e54244c0$afc6ce40$@lanthaler@gmx.net>
On Monday, April 29, 2013 4:13 AM, Martin Nally wrote:
>> Which is almost the same as flattened JSON-LD [2] except that it
>> isn't indexed by S.
> 
> Yes, but being indexed by S is the key characteristic that made
> programming to the data simpler. [What we were actually using was
> something like "framed-exapanded", because MongoDB will not store
> expanded - it breaks the outer array into multiple documents.]

Yes, we have been aware of this for a long time but decided to not support
it in JSON-LD 1.0.
See http://json-ld.org/minutes/2012-09-04/#topic-3

You still haven't answered my question though. Is it possible for you to
shape your data as follows:

{
  "@context": {
    "data": { "@id": "...", "@container": "@index" }
  }
  "@id": "top-level-node, probably eq. document URL",
  "data": {
    "subj1": { "@id": "subj1", ... other properties ... },
    "subj2": { "@id": "subj2", ... other properties ... },
    ...
    "subjn": { "@id": "subjn", ... other properties ... },
  }
}

That would allow you to serialize the data in almost the same way. 


> The way our python servers actually work makes it simple for us to
> accept and produce different RDF formats. The business logic in all
> our servers always consumes and produces python data structures whose
> organization is {S : {P : O}} (error results are currently an

Would wrapping it in a structure like

{ S_outer, container: { S: { P: O } }

be a viable option?


> exception to this rule). If the client asks for HTML, we serialize the
> response as HTML/RDFa at the last moment before putting it on the
> wire, and if the client asks for JSON or RDF/JSON, we serialize the
> response by just dumping the data structures as JSON. It would only
> take me an hour or two to make all our servers optionally return some
> form of JSON-LD, but the only clients we have currently are ones we
> wrote ourselves, and they find RDF/JSON more convenient to consume. We

Just out of curiosity, what are those clients doing with the data?


> will be happy to consider providing JSON-LD when we have a client that
> wants it. When that happens, it will be interesting to see if they
> will accept any JSON-LD - presumably because they have implemented the
> whole JSON-LD spec - or whether they will ask us for one particular
> JSON-LD format. Similarly, if we accept JSON-LD on input, we will have
> to decide ourselves what variants in the complete JSON-LD spec we need
> to implement. If we have to accept the whole JSON-LD spec on input,
> that will be rather costly unless we find a commercial-quality library
> that implements it for us (none identified yet). These questions don't
> really arise with RDF/JSON because of its simplicity, and in fact one
> of the attractive characteristics of working with RDF/JSON is that we
> have found that we really don't need any RDF programming libraries at
> all. What we currently use for both the python servers and the
> JavaScript clients are the standard JSON libraries, plus slightly less
> than 200 lines of simple helper methods that we wrote ourselves.

So summed up, if there would be a JSON-LD profile which allows you to get
the data in a similar shape as RDF/JSON it would satisfy all your
requirements? Or would you still prefer RDF/JSON in that case because it's
spec is much shorter and you can use a different media type instead of
having to rely on a media type parameter?


Cheers and thanks for your patience :-)
Markus



--
Markus Lanthaler
@markuslanthaler
Received on Monday, 29 April 2013 10:26:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:59:32 UTC