-
Notifications
You must be signed in to change notification settings - Fork 2
Components
The underlay is a data model and set of protocols that facilitate data interoperability and federated services such as distribution, discovery, cleanup, alignment, subscription.
Components below describe an older conception of the model; being updated as of 12/19.
The underlay data model describes an entity used in the protocols: an 'assertion'. An assertion is a claim by a source, with detailed provenance. It is schema agnostic.
Assertions are sourced claims of fact, rather than statements assumed to be fact. The underlay model does not try to resolve whether a claim within an assertion is valid. This is left as a service to be provided by higher-order infrastructure.
Data in an underlay system is composed of a set of assertions. Assertions can be sharpened by decomposing them into a set of more specific assertions, or by otherwise extending the tree of provenance links.
The underlay protocol defines a set of services and their interfaces. These services could be built using any technology, combined into a single server, or distributed across many servers. The protocol defines only a set of required and recommended interfaces. This lets underlay service developers build services with their toolchain of choice.
Submit assertions for sharing with the network.
Subscribe to a set of future assertions, or current assertions* (as a dump of stored content).
Query for assertions using structured language, Returns a set of assertions.
Serach for assertions with unstructured language, Returns formatted or summarized overviews of assertions. (A higher level service on top of querying)
Register a key or identifier with the service.
An underlay node is not an officially supported element. A node is a configuration of one or more underlay services packaged in a way to let people participate in an application. Running a node means running software that makes you part of a network supporting specific applications and services.
A node w/ id mgmt, policy management, timestamping?
[what makes a healthy/unhealthy registry?]
Catalog of registries -->
Registries run these; clients also run these. See https://github.com/underlay/pkgs
Imagine CLI tools invoking this on the equivalent of upm-get; and end users run these w/ their own index packages. That's how you retrieve and manage local data. Then the target styx interface can be as a plugin for pkgs.
Build arbitrary indices for data in your index package. That shows the data you want to index (in a db sense); it will pipe in appropriate data [things matching a certain shape] for you to run efficient local queries. A styx index would let you do subgraph queries; there could be others too. This is where you can get fulltext pdf search or postgres or sparql parsing.
You could have your user acct on a registry, but also production services available via the registry. --> service to charge for. [contrast w graphql service ecosystem] 'everything in your user pkg will get into postgres, via this connection' -- w webhooks &c. Bus model is accessibility.
"why does everyone use graphql but not datalog?" --> https://news.ycombinator.com/item?id=21738331
The underlay is a set of recipes for tools that let data integrate easily with other sets of data.
All data in an underlay system is stored in an 'assertion'. An assertion is a set of specifically formatted data. Perhaps the simplest way to imagine what an assetion is, is to imagine it as a text file. You could store these text files in any way you like: as individual files, as rows in a database, pieces of paper in your drawer.
The goal of Underlay services is to provide the tools to allows the assertion files to be easily shared, sent, accessed, queried, and integrated with another person's set of assertion files. While the internet allows the sharing, sending, and querying of a data, aligning and integrating disparate data sets remains hard. (Is an assertion / docket an expanded packet?)