Re: RDF/JSON

I have to answer this two ways.

For an audience that already understands and accepts the value of RDF, and
that also accepts the value of JSON-LD, your proposed format would satisfy
the requirements - it provides the desired data organization.

For the world I live in - a population of programmers only a few of whom
really "get" RDF, and even fewer who believe in the value of JSON-LD - it
looks like adding more complexity on top of something that is already too
complex. IMO, even the programmers who really "get" RDF, are likely to have
this reaction and the ones who "get" JSON and are just beginning to
understand the value of RDF will have it even more strongly.

Best wishes, Martin


On Mon, Apr 29, 2013 at 6:25 AM, Markus Lanthaler
<markus.lanthaler@gmx.net>wrote:

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