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

Hi Kingsley,

 >> Let me ask my question differently: in a world where structured data is accessible via HTTP, query services (like SPARQL), and constrained by an abstract data model (e.g., EAV, RDF etc..), is there any reason for MongoDB needs to be in the conversation re., Javascript based libraries and frameworks aimed at data access?

Ah now I understand what you mean.
So when we abstract SPARQL result sets using a JSON document layer, and we want to query the JSON, then suddenly we need a query language for JSON.
So the reason I am talking about the  mongoDB "query language" is because it is one that seems quite easy to implement.

In fact, the querying is to some extent a "bonus": Even without the query capability, the SPARQL-to-JSON mapping would have its merits because one gets JSON documents without programmatic efforts.

For the sake of conceptual completeness: One could insert another layer of abstraction that maps the mongo-db query language to an (intermediary) query language (or better: algbra) for JSON, which then is compiled to SPARQL.
Probably XPath and/or XQuery would come closest to this. If you know of a JavaScript framework that would give one a kickstart with this, this would be very interesting.
But I am not sure I want to write a query-rewriting engine for this - Especially since I am already doing this for the Sparqlify system which rewrites SPARQL queries to SQL over e.g. the OpenStreetMap schema, and at some point I actually want to finish my PhD ;)


 >> I have zero interest in platform specific technology, once I smell leaks in abstraction I simply move on. I need to know if I should invest any of my time looking at this work. Bottom line, can I get this stuff up an running without MongoDB or any other platform specific bits (e.g, nodes.js) ?

This is perfectly fine with me - If with your experience you think a layer of abstraction is missing, I'd be happy to hear about it.
Jassa (and thus also the Sponate module) is aimed at (and the prototype does) working purely in the browser (without service-dependencies except for a (CORS-enabled) SPARQL endpoint) *as well as* server side with nodejs.

In fact, a server side example where I used Jassa with nodeJs for geocoding is here:

https://github.com/GeoKnow/GeoKnow-Scripts/blob/master/geocode-avifbr/geocode-rdf/geocode-rdf.js

In this example, pieces of address information (unfortunately it was internal data) stored in a SPARQL endpoint are mapped to JSON documents using Sponate. The documents then needed post processing because the data in the SPARQL endpoint was somewhat dirty. Yet, at no point did I have to programmatically map the SPARQL to JSON.

Maybe it is worth mentioning that the Jassa API design is similar to Apache Jena - this means, a SELECT query returns a (promise to a) result set *object*, which offers a nextBinding() method - so although the current implementation only supports Talis JSON RDF, conceptually one could add other parsers as well.

(Actually, this would be a nice little project integrating some of the existing parsers for this - but then... Hey wait! Why do we have JSON-LD - shouldn't syntaxes be abstracted away anyway??? ;) )

Anyway, for server side use, the API design would thus - without further change - also allow for streaming result sets (not sure to what extend this is actually possible with NodeJS)



Cheers,
Claus


On 04.12.2013 23:45, Kingsley Idehen wrote:
> On 12/4/13 5:08 PM, Claus Stadler wrote:
>> I guess something similar as this extension for LevelDB: https://github.com/eugeneware/jsonquery-engine
>> "A full MongoDB query language implementation with INDEXES for querying your levelup/leveldb database."
>>
>> Yes, this is similar to what we are aiming at with Jassa/Sponate - except that we want to have it with a SPARQL endpoint as the backend (via a set of declarative SPARQL-to-JSON mappings).
>
> I am still confused about what being articulated above. Please note, I've been designing and using data access virtualization layers (in various guises) for 20+ years.
>
> Let me ask my question differently: in a world where structured data is accessible via HTTP, query services (like SPARQL), and constrained by an abstract data model (e.g., EAV, RDF etc..), is there any reason for MongoDB needs to be in the conversation re., Javascript based libraries and frameworks aimed at data access?
>
> I have zero interest in platform specific technology, once I smell leaks in abstraction I simply move on. I need to know if I should invest any of my time looking at this work. Bottom line, can I get this stuff up an running without MongoDB or any other platform specific bits (e.g, nodes.js) ?
>
> Kingsley
>>
>> Cheers,
>> Claus
>>
>>
>>
>> On 04.12.2013 22:12, ☮ elf Pavlik ☮ wrote:
>>> On 12/04/2013 08:17 PM, Kingsley Idehen wrote:
>>>> 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.
>>> I guess something similar as this extension for LevelDB: https://github.com/eugeneware/jsonquery-engine
>>> "A full MongoDB query language implementation with INDEXES for querying your levelup/leveldb database."
>>>
>>> I understand that one can use popularized by MongoDB query language without using MongoDB itself...
>>>
>>> In case mentioned above LevelDB extension it should even run smoothly in a web browser on top of IndexedDB using for example https://github.com/maxogden/level.js "level.js an implementation of the leveldown API on top of IndexedDB (which is in turn implemented on top of LevelDB, which brings this whole shebang full circle)"
>>>
>>>
>>
>
>

-- 
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 23:38:44 UTC