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

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

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.

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.

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 (?)


>> (Kingley wrote) You mean "your object representation" or maybe a "JSON object representation" crafted by you :-)

I meant: The user decides on how to craft his JSON ;) Of course within the constraints of the system which have to be (a) documented and (b) explored.



 >>  (Kingsley wrote) Is there a way that one could evaluate your stuff (currently) without MongoDB?

I have set up another demo example (with Jassa.js merged into a single file) in
https://github.com/GeoKnow/Jassa/tree/master/jassa-demos/fp7

for playing around, you can just serve the folder with e.g. Apache2 (you need php and curl).

This demo shows projects, their partners, and how much money they got (more info here: http://fp7-pp.publicdata.eu/)

and I deployed it here:
http://cstadler.aksw.org/jassa/fp7/

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'
  });



Filtering is currently case-sensitive and operates on the names.

But as I said: Without the server side filtering support, Sponate is not of much use in real world use cases yet!
So please be aware that Sponate is really an early prototoype, but I think the approach is worth of being communicated to the community :)


 >> (Kingsley wrote) I am getting more confused, *simple* is deepening said confusion based on its proximity to MongoDB in the sentence above.


Of course, simple is always relative ;)
With MongoDB-like interface I mean that you can do something like this:

         criteria = {$or: [ { name: {$regex: filterText } } , { partners: { $elemMatch: { name: { $regex: filterText } } } } ] };

 var promise = store.projects.find(criteria).skip(0).limit(10).asList();


Compare this e.g. to <http://docs.mongodb.org/manual/reference/operator/query/elemMatch/#op._S_elemMatch>

If you only wanted to filter the project's names, the criteria only becomes:

     criteria = {name: {$regex: filterText } }

If one wants to build a criteria over multiple attributes, of course it is worth considering creating a helper function for that.

This criteria matching works currently fine on the client side, but obviously, one can compile e.g. the regex-constraints into SPARQL filters - which would prevent Sponate from fetching multiple thousands of result set rows :)

Alternatively, one can also consider using bif:contains - but this is getting too detailed ;)

Cheers,
Claus


On 04.12.2013 20:00, ☮ elf Pavlik ☮ wrote:
> On 12/04/2013 07:14 PM, Claus Stadler wrote:
>
>> The thing is, that there is an impendance mismatch between SPARQL
>> (result sets) and JSON, which is not overcome by just representing
>> triples or RDF terms in whatever serialization format.
>> *The main point is, that you need to transform the data into a data
>> model that is aligned with the requirements of the view!*
> Actually I currently face such challenge in small open source project where I use Backbone.js. This evening I plan to investigate http://json-ld.org/spec/latest/json-ld-framing/ (spec bit outdated according to Markus Lanthaler who suggests investigating existing implementations instead!)
>
>
>

-- 
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 Wednesday, 4 December 2013 21:14:32 UTC