The word `context` is confusing in the intro

[BigBlueHat]

First, thanks for building this project!

Second, I found the use of the word context confusing in the introduction

Especially: (subject, predicate, object, context)

Most other quadstores/libraries express that as (subject, predicate, object, graph) (in my limited experience).

Change it would a) match prevailing convention and b) avoid tripping folks up coming from JSON-LD land where @context is something completely different.

Cheers! 🎩

[jacoscaz]

Hello @BigBlueHat . Thank you for your feedback, we appreciate it. I hadn't thought about the possibility of context being confused with JSONLD's @context. Perhaps, in addition to changing the introduction, the default value for the contextKey option (https://github.com/beautifulinteractions/node-quadstore#quadstore-class) should be graph. What do you think?

Also, are you thinking of using quadstore in a project? We've created issue #18 to keep track of (early) users. Feel free to comment over there.

[BigBlueHat]

Yeah, I'd change it throughout--at least if your focus is RDF-based input.

Is there a difference between context and graph? Especially as regards this paragraph:

The contextKey option determines which key the store will use to read and write the context of each quad. A value of graph requires all quads to be formatted as { subject, predicate, object, graph } objects. Similarly, the default context value requires all quads to be formatted as { subject, predicate, object, context } objects.

I guess I don't see the need for a distinction between the spog and spoc objects nor of having it be configurable (again assuming RDF).

[BigBlueHat]

I'll be keeping an eye on quadstore, for sure, but I'm pretty committed to LevelGraph these days (see https://wileylabs.github.io/levelgraph-playground/ for one).

My hope, though, is that all of this becomes "core" or "shared" across these libraries. Ideally, we'll all work together to reduce the measure of differences, but continue to innovate for our own needs/use cases.

Collaborate FTW and all that. 😸

[BigBlueHat]

Here are the terms that the N-Quads spec uses:

[1]     nquadsDoc   ::=     statement? (EOL statement)* EOL?
[2]     statement   ::=     subject predicate object graphLabel? '.'
[3]     subject     ::=     IRIREF | BLANK_NODE_LABEL
[4]     predicate   ::=     IRIREF
[5]     object  ::=     IRIREF | BLANK_NODE_LABEL | literal
[6]     graphLabel  ::=     IRIREF | BLANK_NODE_LABEL
[7]     literal     ::=     STRING_LITERAL_QUOTE ('^^' IRIREF | LANGTAG)?

So--within that spec at least--they use the term graphLabel (rather than the more frequently seen graph term).

Interestingly, the document that pre-dates this actual spec was called "N-Quads: Extending N-Triples with Context." So. It's not a new term conflict apparently. 😃

Cheers.

[jacoscaz]

@BigBlueHat thank you for pointing me to those documents. Much appreciated. With the QuadStore class we aim to implement a quadstore that makes as few assumptions as possible about the sort of quads it has to deal with. Hence why the fourth term's key is configurable. However, the vast majority of interest in quadstore comes from the RDF world and we ourselves are working on it because we need full support for RDF quads, hence why I think we'll end up changing the default setting of contextKey to "graph" as you suggested.

[jacoscaz]

Too late to fix the commit's title (no backticks allowed!), unfortunately. This should now be fixed.