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

Hi Kingsley,

 >> Yes, but why do you now introduce a MongoDB dependency?
I think you misunderstood me.

Sponate offers a *virtual* MongoDB interface, which is backed by a SPARQL endpoint.
There is no *actual* MongoDB behind.

The MongoDB interface is just super simple to use from a Web application developer perspective, and is well known and (relatively) sufficient for querying JSON documents.


 >>  A lot of work that I believe can be negated by just using SPARQL, Triples (represented in RDF/JSON, JSON-LD if you choose) alongside HTML5 and CORs.

Isn't this exactly what the Sponate example demonstrates? It queries CORS enabled DBpedia, maps the RDF/JSON (sparql result set) to a JSON document and lets AngularJS render the HTML(5).


 >> What happens when a SPARQL endpoint returns SELECT query results in JSON?

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!*
Put differently: Conceptually, Sponate allows you to work on the *object-level* in contrast to the *SPARQL binding / triple level*.

For example, consider the demo at <http://cstadler.aksw.org/jassa/sponate/>:
It shows a list of castles and their owners, howewever, each castle is represented by a JSON *object* and it has the attribute 'owners' which holds an *array* of owner *objects*.

So you could do an iteration like this:

foreach (castle in castles) {
    foreach(owner in castle.owners) {

    }
}

With AngularJS, you can render JSON objects as views just like this (the loops are *emphasized*):

<table class="table table-striped">
	<tr><th>Image</th><th>Name</th><th>Owners</th></tr>
	<tr *ng-repeat="castle in castles"*>
		<td><img class="image" src="{{castle.depiction.slice(1, -1)}}" /></td>
		<td><a href="{{castle.id.slice(1, -1)}}">{{castle.name}}</a></td>
		<td>*{{(castle.owners | map:'name').join(', ')}}*</td>
	</tr>
</table>


I hope I could clear up a bit of confusion ;)

Cheers,
Claus


On 04.12.2013 18:05, Kingsley Idehen wrote:
> On 12/4/13 11:27 AM, Claus Stadler wrote:
>> Hi list,
>>
>> I feel its time that we share some information of JavaScript related projects we are working on:
>>
>>
>>>> My vision is that power users will be able to create/adapt views
>>
>> This is also our vision, but we are using a different approach:
>> Rather then describing views in RDF, we just embrace the AngularJS framework and
>> work on a SPARQL-to-JSON mapper called Sponate for this purpose.
>> In a nutshell, Sponate is a combination of the words SParql, jsON and hiberNATE, and allows you to aggregate
>> SPARQL result sets into JSON documents.
>>
>> Based on these JSON documents, Sponate then offers a MongoDB interface for querying (check http://docs.mongodb.org/manual/reference/operator/query/).
>> And the best thing: AngularJS makes the creation of interactive views based on JSON documents a real breeze!
>
> Yes, but why do you now introduce a MongoDB dependency?
>
> What happens when a SPARQL endpoint returns SELECT query results in JSON?
>
> What happens when a SPARQL endpoint returns DESCRIBE and CONSTRUCT query results in JSON-LD or RDF/JSON?
>>
>>
>> An very initial demo is available here (check the source code of the page).
>>
>> http://cstadler.aksw.org/jassa/sponate/
>>
>>
>> Right now we are working on translating MongoDB criteria queries into corresponding SPARQL graph patterns.
>> The demo only features client side filtering, which is pretty useless for large result sets ;)
>>
>
> Why don't you stick with SPARQL and triples? Why the MonogoDB dependency, I ask again?
>
>> Furthermore, we are combining this approach with the 'Facete' library, which will eventually offer client side SPARQL based faceted search over the Sponate views.
>> (Hope to have a demo on this in 1 or 2 weeks)
>>
>> For managing the complexity, we are developing these efforts under the name
>> Jassa - which stands for JAvscript Suite for Sparql Access.
>>
>> https://github.com/GeoKnow/Jassa
>>
>> It re-uses many design patterns of the Apache Jena project - I didn't feel there was a need to invent some JavaScriptish/JSONish API which gets more messy to use as the complexity increases :)
>>
>> Maybe its also interesting to mention, that Jassa builds on prior expertise we collected from the following projects:
>> 'Sparqlify': SPARQL-to-SQL rewriter (https://github.com/AKSW/Sparqlify) (Sponate is is some way similar to SPARQL-to-SQL rewriting, yet different)
>> 'Facete SPARQL Browser': (http://cstadler.aksw.org/facete/), Application from which we are factoring out the faceted search JavaScript library 'Facete'
>> 'Jena SPARQL API' (https://github.com/AKSW/jena-sparql-api): Utility library with a Sparql service abstraction as to not have the application layer to worry about caching, delays, pagination, and temorary failures.
>> 'Mappify': (https://github.com/GeoKnow/Mappify) Customized creation of interactive maps from spatial RDF data - based on Jassa - first public relase planned in January.
>>
>> If anyone is interested in joining efforts, that would be awesome :)
>> For example, I would love to adapt/integrate a Sparql parser into Jassa, such as for query optimization.
>
> A lot of work that I believe can be negated by just using SPARQL, Triples (represented in RDF/JSON, JSON-LD if you choose) alongside HTML5 and CORs.
>
> I am hoping that this group is ultimately about solutions that are loosely coupled i.e., no dependencies beyond Javascript, HTTP, CORs, and structured data.
>
> Kingsley
>>
>> Best,
>> Claus
>>
>>
>> On 04.12.2013 16:42, Adrian Gschwend wrote:
>>> On 04.12.13 12:37, Ruben Verborgh wrote:
>>>
>>> Hi Ruben, hi Michael,
>>>
>>>> That sounds cool. Would you have a demo somewhere? Also, I like the
>>>> word "adaptive" in there and I wonder whether it could be a nice
>>>> application of streaming. We could imagine the simple case of the
>>>> visualization updating as a large Turtle file comes in, but also
>>>> updating iteratively as more and more data is explored. For instance,
>>>> if a user activates a node, data is pulled from the Web through
>>>> dereferencing.
>>> would be cool indeed. The idea is to use the power of RDF to create
>>> adaptive views. When I started working with RDF a few years back I was
>>> very frustrated with the visual interface layer, which was back then
>>> basically non existing. Now we have at least some choice but what bugs
>>> me is that with RDF I get a highly adaptive data model (at least
>>> compared to everything else I know) but I still have to create views the
>>> way I did it since I started playing with PHP & SQL 15 years ago. Like
>>> more or less hard wired views on a (again mostly hard wired) queries.
>>>
>>> So in this project we try to come up with a layer which decouples this.
>>> You can describe a view in RDF, using classes & attributes to describe
>>> what this view should consist of. When we get RDF data (via
>>> dereferencing or via query) we analyze what we get, try to find a
>>> matching view (or might ask the user to choose one if we have more than
>>> one) and hand it to a "renderer". In the rendering I can use different
>>> templates for different devices or interfaces. Like this we can show
>>> different representations of the same data and the same view on
>>> different devices (or user preferences). We try to do this as generic as
>>> possible but as specific as necessary.
>>>
>>> My vision is that power users will be able to create/adapt views and
>>> share them (as RDF graphs) among other users. The UI elements can also
>>> be more or less generic (container like principle) so they can get
>>> shared and combined within certain boundaries.
>>>
>>> For those who did work with Frenel: It goes into a similar direction but
>>> differs in details and implementation (for reasons I will describe when
>>> we have some demos).
>>>
>>>
>>> regards
>>>
>>> Adrian
>>>
>>>
>>
>
>

-- 
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 18:14:58 UTC