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

Hi Markus,

Thank you very much for the clarification and your efforts for the examples.

>> You see that they are more or less the same.

The devil is in the detail :)

Your remarks strengthen my opinion that JSON-LD and Sponate serve complementary goals (unless I completely misunderstood something, which I don't think I did :)
JSON-LD framing preserves the original RDF graph (i.e. structure) and the information, whereas the goal of Sponate is to simplify restructuring of the data matched by a given graph pattern.
Also, Sponate aims at use cases where information loss is not an issue - such as when rendering a table with only specific information (as you have seen from my demos).

So, I guess it is valid to say that JSON-LD is closely related to RDF level, whereas Sponate is closer to the SPARQL level (and SPARQL builds on RDF).


 >> I don't understand what you mean by "join a Sponate 'View' with a SPARQL graph pattern
Yes, this is a bit abstract right now. I'll show what I mean when I have the demo ready (hopefully the coming week, but might also be a bit longer).

Cheers,
Claus


On 05.12.2013 20:52, Markus Lanthaler wrote:
> 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
>
>
>

-- 
Dipl. Inf. Claus Stadler
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org/
Workpage & WebID: http://aksw.org/ClausStadler
Phone: +49 341 97-32260

Received on Saturday, 7 December 2013 00:20:49 UTC