LDflex over In-Memory RDF Data

Hi,

Is there a way to use the proxying approach over in-memory data so that the await is no longer necessary? it feels quite clumsy in cases where all data RDF data is locally available anyway.

For my use case I just want to import static RDF files (or fetch an RDF graph in batch from an endpoint), and then have a resource-centric view over it (in contrast to triple based ones), and finally have a JavaScript proxy over it that exposes outgoing and ingoing triples as virtual JSON attributes - in the simplest case by just matching magic JSON atttributes to RDF local names.

To illustrate it conceptually step-by-step:

# expample.ttl

@prefix eg: <http://www.example.org/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

eg:Foo eg:relatesTo eg:Bar .
eg:Bar rdfs:label "Bar" .

// Load a string or JSON representation of a batch of RDF from whatever source - possibly async
var stringOrJson = loadRawRdf("example.ttl")
// If I am not mistaken, import only works for JSON, so only for json-ld we could do "import data from 'example.jsonld'"

// Make the RDF string/json accessible using a proper RDF-API
var model = makeRdfModel(stringOrJson)

// Get a resource centric view
var resource = rdfModel.getResource("http://www.example.org/Foo")

// Now comes the proxy magic:
var fooProxy = makeRdfProxy(resource)`

// In general, properties in RDF are multi-valued, so in general it maps to an (unordered) array view
console.log(fooProxy.relatesTo[0].label)
// Output: Bar

// On the array proxy, try to delegate all calls to element [0] if no array index is used
console.log(fooProxy.relatesTo.label)
// Output: Bar

The main benefit is, that one can then really create fuzz free HTML views just like:

<template>
  <h1>Hello {foo.relatesTo.label}</h1>
</template>

[Aklakan]

Hm, so the datamodel and dataset API seem very synchronous to me. Are other components actually using this model? Especially, can the existing parsers output a dataset ? Well, one can always assemble from a set of async quad events.

So having an interface for a set of quads with a synchronuous match(g, s, p, o) method is already a good start - although I am a bit worried not seeing a graph abstraction (triples). Because typically one navigates from a node within a graph to other nodes within the graph - unless one explicitly creates a union-graph (again a graph) view over all named graphs in the dataset. So my impression is, that there is a fundamental interface missing 😦

W.r.t async calls, if they are used to fetch graphs or datasets at once, then there is no issue, because once it is placed as a whole into the (view) model, the view can update itsel synchronously afterwards (I am thinking of vue2 models now).

[RubenVerborgh]

Is there a way to use the proxying approach over in-memory data so that the await is no longer necessary?

Yes, in the sense that LDflex wiring is completely configurable. So by rewiring this, you can have other behavior.

However, it would be difficult in the sense that:

• LDflex depends on a lot of components and interfaces that only have an asynchronous implementation.
  • Thinking concretely about JSON-LD context parsing, which can involve network requests and thus needs to be asynchronous. You could plug in a simplified JSON-LD parser that skips these and thus is able to work synchronously, but you’d most probably have to write that first (as I am not aware of any implementations).
  • The Comunica query engine is also asynchronous; however, we have a query engine implementation with RDFlib.js (https://github.com/LDflex/LDflex-rdflib) that could be made synchronous.
• LDflex relies on data.things.foo.bar and await data.things.foo.bar being different things. If they are not, then you would have to execute a query on every step, i.e., data.things, data.things.foo, data.things.foo.bar, even if you only need the last result.
  • Unless, of course, you go for a synchronous property or method like data.things.foo.bar.items.

it feels quite clumsy in cases where all data RDF data is locally available anyway.

Yeah, but so as mentioned above, there is thus still the JSON-LD parsing and the querying that is asynchronous, and the fact that await is also used as a trigger for “just query it now”.

The main benefit is, that one can then really create fuzz free HTML views just like:

I see the appeal indeed. That would not be impossible to wire, but would take some implementation work.