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

Hi Michael,

>> What was the design goal of this mapping?

The design goal number one is make it as simple as possible to get JSON documents with customized structure from SPARQL result set
The cool thing about JSON is, that (a) simple processing tasks are easy to accomplish, and (b) it works so darn well with latest generation web frameworks - i.e. AngularJS - maybe also Ember.js, but I haven't used the latter.
Personally I can say: After two years of pain with JQuery and BackboneJS (partly KnockoutJS), I can say that AngularJS brought the fun of front end development back ;)

The second design goal is - in cases where the JSON is used for rendering HTML tables - to enable simple filtering - that's where the MongoDB interface comes in.

>> How is it implemented? (Did you create a parser, or some hand mapping?)

The mapping you see in the example can be seen as the syntactical representation (based on JavaScript syntax). This syntax is then parsed into an object structure; the base class is called 'Pattern'.
A Pattern is the blue print for the JSON document to create.
Upon processing a SPARQL result set, Aggregator objects are created based on the pattern as needed.
Each Aggregator has a process(binding) method, whereas a binding corresponds to a row in the SPARQL result set.
So technically, creating JSON documents from SPARQL result sets is an aggregation function.

For example, the AggregatorMap evaluates the (SPARQL) id expression that was given in the Sponate template, and then decides whether a new child Aggregator has to be created, or whether an existing one can be re-used.
https://github.com/GeoKnow/Jassa/blob/master/jassa-js/src/main/webapp/resources/js/sponate/core/sponate-core.js#L817

Once processing of the SPARQL result set is complete, the toJson() method of the root-aggregator object is invoked, and each aggregator then returns its contribution to the final JSON document.

>> Does it work with multiple recursive levels or is it limited with 2 levels?
In theory it should work with arbitrary depth - but its not tested yet.

Also, note that there is no official Sponate release yet (planned for end of January).

  
>> Can Sponate on a abstract level be described as a mapper from a potentially cyclic graph to a tree structure?
Hm, let me rephrase:
As Sponate is based on SPARQL result sets, there is no (RDF) graph.
Sponate essentially maps SPARQL result sets, specified via SPARQL graph patterns.
And the SPARQL graph patterns can match data from potentially cyclic RDF graphs - I hope my description is clear? ;)


>> 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.
In the future I envision being able to declare relations between multiple mappings - similar to how Hibernate is capable of expressing the cardinality between classes using the @OneToOne, @OneToMany, @ManyToOne and @ManyToMany annotations - but I can't estimate how long it takes to conceptualize and implement this. For now I can only say that I have this in the back of my head while designing the system.
  

Cheers,
Claus


On 05.12.2013 08:20, Michael Luggen wrote:
> 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 investigatehttp://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
>>
>>
>

-- 
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 Friday, 6 December 2013 23:56:08 UTC