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

H Claus,

Appart from the other interesting stuff, my attention got mostly the Sponate mapping. Can you tell me more about? What was the design goal of this mapping? How is it implemented? (Did you create a parser, or some hand mapping?) Does it work with multiple recursive levels or is it limited with 2 levels? How would you include language folding? (Means to provide to the JSON structure all language available per Literal?)

In the system we try to build, we need actually one component which extracts out of a graph a tree structure. Can Sponate on a abstract level be described as a mapper from a potentially cyclic graph to a tree structure? Our approach would than be to match smaller portions of the graph and find multiples of this smaller portions. In your example instead matching a list of Partner per Project we would just match Partners in another Mapping and the ask a multiple of Partners with the connection to a Project.

Happy to hear any thoughts!

Michael

On 04.12.2013, at 22:14, Claus Stadler <cstadler@informatik.uni-leipzig.de> 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 :(
> 
> 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 Thursday, 5 December 2013 07:23:48 UTC