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