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

On 12/4/13 1:14 PM, Claus Stadler wrote:
> 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.

Hmm.. I am a little confused by *virtual* MongoDB interface.

>
> 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.

I am getting more confused, *simple* is deepening said confusion based 
on its proximity to MongoDB in the sentence above.
>
>
> >>  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).

I will take a look.

>
>
> >> 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!*

Yes, and I know that. We've built JS interfaces to RDF data sources for 
years [1][2].

> Put differently: Conceptually, Sponate allows you to work on the 
> *object-level* in contrast to the *SPARQL binding / triple level*.

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

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

I will revisit knowing that there isn't a MonogDB dependency that would 
otherwise distract me :-)

Links:

[1] http://oat.openlinksw.com -- old now, was built in 2007 (some of the 
demo links are broken)
[2] https://github.com/openlink/html5pivotviewer -- PivotViewer

Kingsley
>
> 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
>>>>
>>>>
>>>
>>
>>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen