Scope of the spec and this repository

[bergos]

In the past we discussed a lot of stuff which didn't make it into the spec yet. One approach was to group it into a high and low level spec. I think this was still to blurry and just lead to a lot of discussions with no outcome so far. I would propose to keep the scope of the spec like it is now. Further topics can be discussed and specified in separate specifications, similar to the Dataset Spec. This would allow us to close/move many issues and get closer to finalize the spec.

Here is a list of issues which would be affected:

• 13 Consider naming WRT literals to be consistent with RDF 1.1 and XSD 1.1 specs

• 15 Prefix map handling

• 17 Converting from JavaScript values to RDF values and back

• 33 Can .triple and .quad also support simple strings, plain objects, or should they be Terms?

• 44 Optional options parameter for all source, sink and store methods

• 49 Create an interface to shrink and expand CURIEs

• 72 define which value is used for the RegExp test in .match

• 84 write a more detailed description of Dataset.equals

• 85 Where and how will we work on the HighLevel API?

• 86 To reflect the new HighLevel API effort update the Readme to include

• 87 Write a Mission Statement for the HighLevel API (analog to LowLevel)

• 97 Stream events for parsing various serialization formats

• 98 TermMap which supports using predicates in reverse direction

• 100 .parse() & .serialize() helpers

• 108 High level RDF Store api

• 116 Support for prefix map in .namedNode()

• 123 Counting, filtering and additional features

• 128 Store matching RegExps

[RubenVerborgh]

Fully agree. Especially given the adoption for the low-level spec we already have.

[elf-pavlik]

We could transfer (Github Beta feature) relevant issues to https://github.com/rdfjs/dataset-spec and close the rest. Once someone creates another spec addressing some of those issues, they can get transferred there and re-opened.

[bergos]

Please +1 in the next 3 days if you agree or leave a comment if you disagree. I will move the dataset issues to the dataset-spec repo and close the other issues.

[jacoscaz]

I think that filtering and counting features, as I mentioned in #123, belong to the Store interface of the low-level spec. I see them as fundamental primitives for any data storage solution and not supporting them in a low-level spec feels wrong. Beside those, the dataset spec does seem more appropriate for everything else.

[elf-pavlik]

We could also ship Data interfaces and take little more to finalize Stream interfaces. I don't see any drawbacks in having them as two distinct specs.

[bergos]

Maybe we could split it into Data Model and Streams, that separation could make naming and structuring even easier.

Still I'm in favor for separating Streams and Advanced Stream processing (?). Maybe with two specs or like in the Dataset spec. I have two main reasons for it:

• Many implementations don't have a benefit of adding features like RegExp support. It would be just overhead for each library. It should be optional or a wrapper handles extending the interfaces.
• Besides some descriptions, I think we are close to finalize the Stream interfaces like we have them now. Let's not risk that.

[elf-pavlik]

Maybe we could split it into Data Model and Streams, that separation could make naming and structuring even easier.

:+1: I think nailing down streams doesn't need to block the data factory

Maybe we could split it into Data Model and Streams, that separation could make naming and structuring even easier.

I think parsers and serializes do not need RegExp, it seems more like something that would benefit Store.

[bergos]

I moved/closed all mentioned issues.