Support the DAT ecosystem

[almereyda]

The dat-data.com project abstracts streaming data interfaces and data version control. wiki tries to wrap data with visualization, which implies data mangling.

Dat is supported by @maxogden and seems to develop into a modular ETL engine for distributed (micro)service-oriented architectures. Now the federation comes into play. The following just came to my mind:

---

Wiki's drag-and-drop workflow could offer easy instantiation of new dats for a karissa/dathub (pinging @karissa) for example, by offering a compatible ReadWrite API.

Experiments in this regard could mean to

• [ ] offer Newline Delimited JSON support for import and export in wiki-plugin-data. (pinging @finnp)
• [ ] streamline ReadWriteWeb APIs both offer
  • in terms of
  • authorization or
  • the semantics and vocabulary of shared endpoints and,
    • where this plugin may offer additional ones,
  • maybe later even esp. in regards of the Linked Data Platform and wiki and generalized Hydras. (pinging @bblfish)
• share thoughts on
  • [ ] backend-agnostic storage workflows.
  • [ ] distributed versioning and maybe patch-based versioning infrastructures. (pinging @rynomad)
  • [ ] federated Publish-Subscribe (Merge/Fork) scenarios.

[WardCunningham]

I would like to see how wiki and dat could work together. I could imagine a dat plugin that exposed dat data to other pages much like the data plugin but without taking on full responsibility for the dat data. The idea would be to move a wiki near the dat rather than move the dat to the wiki. Results from specific analysis could be cached on a page that travels. Someone who wanted an update would have to rummage through the journal to find the source and return there. Or they could take on duplicating the dat in their environment and running their queries locally.

[almereyda]

Since there is a sneak peek of how such an integration could look like, i.e. forked to https://github.com/federated-wiki/wiki-plugin-datscript, we know that wiki can be an interface to Dat and its pipelining environment. Both environments store their data with content addressable items. Both evaluate IPFS as an option for their storage backend. Each of these three components aid their users in exposing valuable interfaces for data transmission, storage and visualisation. Once web surfers get used to be interacting with a vast diversity of interlinked interfaces, these three can act as pioneers to show how unixoid composeability translates to the Web Platform.

[almereyda]

@paul90 meanwhile maintains a wiki-client-dat-variant.