W3C home > Mailing lists > Public > public-rdfjs@w3.org > July 2014

Re: LDApp Linked Data Stack + RDF-Ext + ... (RDF-Ext in detail)

From: Austin William Wright <aaa@bzfx.net>
Date: Wed, 2 Jul 2014 20:28:56 -0700
Message-ID: <CANkuk-U7oiDGRR6oj1RdRiMf=tgC3qq-mTjqZe=ft67dHyJGzQ@mail.gmail.com>
To: bergi <bergi@axolotlfarm.org>
Cc: "public-rdfjs@w3.org" <public-rdfjs@w3.org>, Read-Write-Web <public-rww@w3.org>, WebID <public-webid@w3.org>
Some additional thoughts:

I've been running into this problem too. Even though I sort of consider RDF
Interfaces a low-level API, if you want asynchronous functions or anything
going over the network, you likely also want functions for dealing with
linked lists (e.g. RDF Collections and other capped containers).

Like SPARQL, for instance. Though SPARQL is a bit too high level for many

I know I brought up, in an earlier message, to public-rdfjs, a proposal for
an IndexedDB-style queries of graph databases:


Another alternative could look something like a transaction:

var tx = createGraphTransaction('http://example.com/endpoint', 'readwrite');
tx.add(new Triple(...));
tx.remove(new Triple('...'));
// Option one, an explicit commit:
var promise = tx.commit();
// Or an implicit commit, IndexedDB-style:
tx.oncommit = function(){
    // Data has been persisted, and `tx` is no longer writable
    // i.e. calls to add() and remove(), etc, will throw an Error

RDF Interfaces does specify a standard API for parsing data into a graph,
however it doesn't support the very recent streaming APIs, as far as I can
tell, you have to send it the entire document at once.

Though I'm not so sure we need to cram everything into a single API. Don't
forget about "RDF API" and "RDFa API":


I'd really like to get around to taking up work on these, again. The
Semantic Web is a complex tangle and needs good tools, disproportionately
more so than other technologies.

I meant to post about another idea I had, putting a JSON-LD "context" in
the prototype of an ECMAScript constructor, so you can turn regular
instances into JSON-LD objects and parse them into a small graph - and
possibly also reverse this process, perhaps isomorphically (to the extent
that Open World Assumption is isomorphic). Then use standard active record
pattern to persist the data in the store of your choice.

Austin Wright.

On Wed, Jul 2, 2014 at 5:11 AM, bergi <bergi@axolotlfarm.org> wrote:

> The announcing mail contained many links, but a lack of documentation.
> In this mail I will explain the intension to create RDF-Ext and some
> details how to use it.
> There is already a number of RDF-Interfaces [1] implementations (webr3
> [2], node-rdf [3], rdfstore [4]). If you look for a standard to handle
> graphs, triples and nodes in JavaScript it's definitely RDF-Interfaces.
> Beside the objects to model graphs, RDF-Interfaces specifies interfaces
> for parsers and serializers.
> >From my experience the most important use case is fetching a graph
> document from a store (the Web is also a store!), parse it and filter
> the triples to get the nodes your are interested in. RDF-Interfaces
> doesn't cover the first step at all and the second step requires manual
> work. So everybody had to implement the HTTP request (Ajax + Node.js)
> and the mime type handling to find the right parser. RDF-Ext covers this
> generic use case with the Store interface. The implementation comes
> already with a LdpStore (works with any RESTful graph data), SparqlStore
> and InMemoryStore. Of course the Store interface also offers methods to
> write to a store. See the current spec [5] for details. During
> development different implementations can be useful to switch from the
> lightweight InMemoryStore to another one with persistence.
> The definition of parsers and serializers in the RDF-Interfaces spec
> don't support asynchronous implementations. But some serializations may
> require additional HTTP requests. For example the JSON-LD context can be
> given as an IRI. The RDF-Ext spec adds a done callback to the process
> method of the parser, which is called after all triples have been
> processed. The serialize method of the serializer interface has a new
> callback which is called with the serialized data as the first argument.
> The RDF-Ext spec is downwards compatible. If an implementation doesn't
> require asynchronous calls both interfaces can be implemented. RDF-Ext
> comes with a Turtle (based on N3.js [6]) and RDF/XML (based on RDFLib.js
> [7]) parser, which supports both interfaces. The JSON-LD parser can be
> only used using the new RDF-Ext interface. All serializers (NTriples,
> JSON-LD) support both interfaces.
> The Store interface is also a good base for other generic stuff like:
> RDF-JSONify is a wrapper around a store to access (read/write) graph
> data using JSON-LD objects. It doesn't matter if your persistence layer
> comes with a SPARQL or LDP interface. The Store implementation handles
> this. RDF-JSONify converts every graph to a JSON-LD object. The JSON-LD
> context can be defined on the request level or for a defined path (Regex
> or prefix). If you don't have to deal with very dynamic data models,
> this maybe the easiest way to handle RDF data in JavaScript. It's the
> perfect combination for frameworks like React and AngularJS. See the
> LDApp [8] blog examples. There are implementations for both frameworks.
> A SPARQL query engine on top of the Store interface is in a very early
> stage. I plan to release it in some weeks. If you are interested and in
> this project and you like to contribute, please contact me.
> Contributions to the other modules are also very welcome.
> [1] www.w3.org/TR/rdf-interfaces/
> [2] https://github.com/webr3/rdf-interfaces
> [3] https://github.com/Acubed/node-rdf
> [4] https://github.com/antoniogarrote/rdfstore-js
> [5] http://bergos.github.io/rdf-ext-spec/
> [6] https://github.com/RubenVerborgh/N3.js
> [7] https://github.com/linkeddata/rdflib.js
> [8] http://bergos.github.io/ldapp-www/
Received on Thursday, 3 July 2014 03:29:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:48:21 UTC