Tomasz Pluskiewicz

It is sometimes useful to take advantage of the `flush` callback to step streams. For example, I used the SHACL step in a way that pipeline does not fail immediately...

Better integrate pipeline validation

1

I propose that we make validation an integral part of barnard CLI - [ ] **Fail fast**: Executing `barnard59 run` should implicitly validate a pipeline at the beginning and stop...

I propose to revert that feature and instead encourage using [`p:FileContent`](https://zazuko.github.io/data-centric.zazuko.com/docs/workflows/reference/loaders#ppipeline) for that and keep only support for the actual key argument

For all known packages which provide a manifest we should collect them and deploy them online, possibly as a trifid instance. In the `barnard59-graph-store` I slightly changed the naming scheme...

We could make an effort to reduce the avoidable redundancy in pipeline definitions - [ ] Remove the need for explicit pipeline type Whether a pipeline is `:Readable` or `:Writable`...

Conditional steps

1

Consider a CSVW pipeline which often looks like below, where we remove the `csvw:` triples. ```turtle @prefix code: . @prefix p: . a p:Pipeline, p:ReadableObjectMode ; p:steps [ p:stepList (...

In PR #152 I added terms to a new namespace which did not exist before: `https://barnard59.zazuko.com/vocab#` We should create a basic documentation, have it dereferencable and redirect to data-centric.zazuko.com when...

Current prototype of such a step from museumplus - Batching prevents high CPU when eye runs too often ```ts import { Readable } from 'stream' import type { Quad }...

* [x] Updated rdf-ext * [x] remove some HTML concatenations * [x] don't use `window` directly