RE: On RDF UIs (Sponate, Jassa, Facete)

On Wednesday, December 04, 2013 10:14 PM, Claus Stadler wrote:
> Hi,
> 
> In regard to: http://json-ld.org/spec/latest/json-ld-framing/
> 
> I've come accross this document some time ago, but I cannot say that I
> fully grasped it. Quite the opposite.
> The spec looks very incomplete and there is no example of what a
> 'frame' specification actually looks like :(

Fully understandable. The spec hasn't been updated for ages. As it became clear that it won't be put on the W3C Recommendation track we effectively stopped working on the spec.


> Yes, the description sounds like it serves a similar goal as Sponate
> but I don't even understand if the spec refers to a JSON-LD-syntax
> specific approach or whether it would work on the conceptual RDF model
> as well - and thus would work with any RDF representation.

You could classify framing as a templating and (limited) query-by-example mechanism. The result is always a JSON-LD document but of course you can feed the processor with data in other syntaxes by translating them to JSON-LD.


> Would be great if someone could enlighten me on this topic :)
> 
> Also, as Sponate is based on SPARQL, this gives the advantage of doing
> SPARQL joins with other graph patterns. I intend to use this property
> to join a Sponate 'View' with a SPARQL graph pattern representing the
> constraints of a faceted search.
> 
> I don't see how I can have this with JSON-LD.

I don't understand what you mean by "join a Sponate 'View' with a SPARQL graph pattern representing the constraints of a faceted search" and thus can't say if you can achieve it with JSON-LD (alone).


> Correct me if I am wrong, but so far I thought that the cool thing
> about JSON-LD is that one can use it with 'legacy' JSON stores, such as
> MongoDB, and have the best of RDF and JSON worlds combined. But I
> thought that eventually, RDF/XML, NTRIPLES, JSON-LD, ... are 'merely'
> different syntaxes for the RDF conceptual model (?)

Right, they are. But since all your frontend code works with just JSON you lose a lot of information during the transformation. If you would pass JSON-LD around, you wouldn't lose any information. The client can then reshape as desired to simplify the processing.


[...]
> The portion that defines the SPARQL result set to JSON mapping is this
> fragment
> 
>   store.addMap({
>    name: 'projects',
>    template: [{
>     id: '?s',
>     name: '?l',
>     partners: [{
>      id: '?f',
>      name: '?pl',
>      amount: '?a',
>     }]
>    }],
>    from: '?s a fp7o:Project ; rdfs:label ?l ;
> fp7o:funding ?f . ?f fp7o:partner [ rdfs:label ?pl ] . ?f fp7o:amount
> ?a'
>   });

OK, taking this as example, you get among others the following triples from your SPARQL server (as JSON resultset):


<http://fp7-pp.publicdata.eu/resource/project/211284> a fp7o:Project ;
    rdfs:label "MolSpinQIP" ;
    fp7o:funding <http://fp7-pp.publicdata.eu/resource/funding/211284-999953019> .

<http://fp7-pp.publicdata.eu/resource/funding/211284-999953019>
    fp7o:amount "240000"^^<http://www.w3.org/2001/XMLSchema#decimal> .

<http://fp7-pp.publicdata.eu/resource/funding/211284-999953019>
    fp7o:partner [ rdfs:label "UNIVERSITAT DE VALENCIA"] .

Converting these triples to JSON-LD without any further processing or context you would get something like this (the prefixed properties would be absolute IRIs of course):

[
  {
    "@id": "http://fp7-pp.publicdata.eu/resource/project/211284",
    "@type": "fp7o:Project",
    "rdfs:label": "MolSpinQIP",
    "fp7o:funding": { "@id": "http://fp7-pp.publicdata.eu/resource/funding/211284-999953019" }
  },
  {
    "@id": "http://fp7-pp.publicdata.eu/resource/funding/211284-999953019",
    "fp7o:partner": { "@id": "_:x1" },
    "fp7o:amount": {
        "@value": "240000",
        "@type": "http://www.w3.org/2001/XMLSchema#decimal"
    }
  },
  {
    "@id": "_:x1",
    "rdfs:label": "UNIVERSITAT DE VALENCIA"    
  }
]

Now this probably is quite inconvenient to work with in your application. But since all the data is there and it is connected, you can simple restructure it according your needs. In this case, you could write a frame like this:

{
  "@context": {
    "id": "@id",
    "data": "@graph",
    "name": "rdfs:label",
    "amount": { "@id": "fp7o:amount", "@type": "http://www.w3.org/2001/XMLSchema#decimal" },
    "funding": { "@id": "fp7o:funding", "@container": "@set" },
    "partner": "fp7o:partner"
  },
  "@type": "fp7o:Project"
}

So in this case the frame consists of just the "@type": "fp7o:Project" query to select the top-level node. The context is just used to compact the long IRIs (which in this case are just the prefixes from the data above, but you get the idea) to compact IRIs. The resulting JSON-LD documents looks as follows:

{
  "@context": ... same as above ...,
  "data": [{
    "id": "http://fp7-pp.publicdata.eu/resource/project/211284",
    "@type": "fp7o:Project",
    "name": "MolSpinQIP",
    "funding": [{
      "id": "http://fp7-pp.publicdata.eu/resource/funding/211284-999953019",
      "amount": "240000",
      "partner": {
        "id": "_:b0",
        "name": "UNIVERSITAT DE VALENCIA"
      }
    }]
  }]
}

If you compare this to Sponate's result

{
  "id": "http://fp7-pp.publicdata.eu/resource/project/211284",
  "name": "MolSpinQIP",
  "partners": [{
    "id": "http://fp7-pp.publicdata.eu/resource/funding/211284-999953019",
    "name": "UNIVERSITAT DE VALENCIA",
    "amount": "240000",
  }]
}

You see that they are more or less the same. The only difference is that the result is nested in a "data" property (which is an alias for @graph in this case, expressing the default graph) and that the "name" of the partner "fp7o:partner" isn't merged into the information about the funding because it belongs to a different node.

Here's a link directly to the playground on json-ld.org demonstrating this (which uses jsonld.js):

  http://goo.gl/wOsDa3

The same works also in Gregg's [1] Ruby implementation or my PHP implementation [2]. There are also implementations in other languages. I hope this clarified framing at least a bit.

I think the advantage is that you can round-trip the data without losing any information. Your application could for example fix a typo in the partners name and send the data back to the server which interprets is as RDF. Doing something like that wouldn't be so trivial with Sonate I suppose.


[1] https://github.com/ruby-rdf/json-ld/
[2] https://github.com/lanthaler/JsonLD


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 5 December 2013 19:53:16 UTC