- avoid URI manipulation at all cost.
for example if you have a /book/foo resource and its chapters, do not mint a /book/foo/chapters URI for a hydra:Collection. this practice will spread like wildfire across resources which are not strictly your domain and also pollute the domain identifiers too.
instead simply create the collection identifier once and persist it somewhere along your data, with a link (reference) to the book it belongs to.
I store RDF so I have </book/foo/chapters> ex:book </book/foo> and use that relation in the queries, thus avoiding the need to explicitly name any resources
an additional benefit is that if you ever change the naming scheme, nothing should break. for example when you migrate from hierarchical URIs like <book/{id}/chapter/{chapter}> to a flat structure </book/{id}> and </chapter/{id}>. the old identifiers should continue to work while the new data has a different naming space
Stream interface not meant to extend NodeJS.ReadableStream on object mode (in @types/rdfjs)? (Refs https://github.com/libero/article-store/pull/64#discussion_r352029306)
1.0 version, but with an experimental message inside, and there doesn't seem to be much tooling.
let dataset: Dataset;
dataset.filter(() => true);Thanks for the replies. Going to halt my work and have a rethink.
DefinitelyTyped/DefinitelyTyped#41016 inspired me to have another crack at using DatasetCore (was aware of the library, but not how to use it), and it seems to solve the problems I was having. Will try and get a draft PR up today, and would appreciate reviews if possible as there's a lot of new concepts/tools that I'm trying to use.
@rdfjs/dataset shouldn't be used, it's only a basic, readable example implementation of the dataset spec. You could replace it with N3 or rdf-dataset-indexed, their perfs are exponentially better
@rdfjs/namespace but ran into problems https://github.com/DefinitelyTyped/DefinitelyTyped/pull/41082#issuecomment-566438477. Will do the rest when I work out what's going on.