gather feedback on Data Model from potential implementers

[elf-pavlik]

Next friday we should close Data Model milestone, which has only two small changes proposed. I find importance in gathering feedback from maintainers of libraries which we hope will implement this spec.

https://github.com/rdfjs/representation-task-force/blob/master/interface-spec.md

an unordered list:

• rdf-ext @bergos | DONE
• graphy.js @blake-regalia | DONE
• node-quadstore @jacoscaz | DONE
• N3.js @RubenVerborgh | DONE
• jsonld.js @dlongley | DONE
• rdflib.js @dmitrizagidulin & @timbl | tracking issue
• green-turtle @alexmilowski ( & @csarven ?)
• GraphRdfaProcessor @sballesteros
• rdfstore-js @antoniogarrote
• LevelGraph @mcollina & @elf-pavlik

If you have membership in RDFJS github orga, please feel free to just edit the list above directly.

[RubenVerborgh]

I think we should do this in 3 phases. First, the library implementers should get some time to implement and test. (I'm thinking 2 months or so.) Second, we should gather feedback. Third, we should provide an updated and final data model.

[elf-pavlik]

Maybe everyone who wants to participate in First phase, as you defined it, could create a working branch in their repository and we could link to it from the list above. I guess no matter what exactly we would like to suggest, you and @bergos can set an example with N3.js and rdf-ext and others could use it as possible source of inspiration.

[RubenVerborgh]

I can do N3.js; I'd closely test for performance impact.

[nicola]

SimpleRDF depends on wrapped library (rdf-ext), and it does not expose these APIs to the final user, unless they use .graph which is any depending on the wrapped library.

[elf-pavlik]

• https://github.com/mcollina/levelgraph-jsonld uses jsonld.js
• https://github.com/mcollina/levelgraph-n3 uses N3.js

Both currently use N3.js internal representation. I will look at possibility of creating rdf-store-levelgraph (following https://github.com/rdf-ext/rdf-ext#stores ) and if that looks promising than discussing with @mcollina deprecating those two levelgraph extensions in favour of rdf-store-levelgraph. I remember we never decided on how to handle quads with hexastore but maybe some fresh ideas will appear now.

[alexmilowski]

I've looked into the interfaces quite a bit and, as Green Turtle is oriented towards graph construction, the interfaces aren't easily integrated without quite a bit of refactoring. As far as the data interfaces, I don't see any particular issues and it would formalize the various bits in the graph (drive out some assumptions).

Meanwhile, the streaming interfaces don't quite match the processing model quite yet. I don't think there is a particular conflict but I haven't worked out how I would expose streams. The parser/transform interface would help with that.

[alexmilowski]

There is a class tradeoff between "pull" versus "push" processors. Whether delivered by events or callbacks, push parsers process a data source and emit information that is pushed towards some receiver. The push processor controls the sequence of downstream processing by invoking some API on a receiver.

The API for a Source is oriented towards pulling information from a source. A receiving application pulls a single quad from a source. When they are read for the next, the source is interrogated for an additional item in the sequence of quads and that invokes the next bit of processing.

It is easy to construct a push processor from a pull processor. The other way around requires a threading boundary or some queuing mechanism.

Green Turtle is currently implemented as a push processor. I would be good to have some support for that push processors regardless of the long-term want for pull processors as a basic mechanism.

[RubenVerborgh]

@alexmilowski Isn't it straightforward to wrap a push processor in a pull processor, e.g., through a buffer?

[bergos]

@alexmilowski @RubenVerborgh The JSON-LD parser wrapper works already that way using the Node.js stream classes. The this.push is called in an async function.

@alexmilowski Working with Dataset(Graphs) in memory like with Arrays is an important feature and we should also spec an interface for it. Maybe not in this spec or milestone, but later. RDF-Ext had already a Graph class, which I will rename to Dataset in version 1 (it's a container for quads, not triples anymore). The initial version was based on the RDF-Interfaces Graph. It looks very similar to the Array interface. I changed it a little bit in version 1 and added methods to handle streams.

[elf-pavlik]

I try to think about an example of how the LowLevel spec enables different modules to interoperate. I see that we have 3 different N-Triples/Turtle parsers:

• https://github.com/RubenVerborgh/N3.js/ @RubenVerborgh
• https://github.com/blake-regalia/graphy.js @blake-regalia
• https://github.com/linkeddata/rdflib.js @dmitrizagidulin

I understand that all of them make different design choices and people would chose one of them depending on requirements of application they build.

Maybe we could come up with simple https://jsbin.com/ which would parse .ttl file and print out triples and one could select one of the three parser with a radio input?

[elf-pavlik]

Another interest in implementing Store interface quadstorejs/quadstore#1 (via LevelGraph issue)

[elf-pavlik]

I just updated initial comment in this issue, it looks like we already have 3 completed implementations - kudos to @bergos @blake-regalia @jacoscaz and 3 work in progress implementations - kudos to @RubenVerborgh @dmitrizagidulin @dlongley

Let's close the test suite issue #47 and make sure all the implementations pass it!

[elf-pavlik]

We do last push for the data-model-spec, if someone subscribed to this issue works on implementation please consider it a last call for feedback!