- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 04 Dec 2013 14:17:12 -0500
- To: public-rdfjs@w3.org
- Message-ID: <529F7FB8.1000608@openlinksw.com>
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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Wednesday, 4 December 2013 19:17:34 UTC