@hoijui described a workflow that he'd like to have, where he can modify some Atomic Data (in this case an ontology of Properties and Classes), and have it hosted somewhere + updated when he commits. Seems achievable, but how?
Have a script that posts commits to an atomic server, run as CI step
Create a tool / script that reads some (predetermined) .jsonad file in a github repo and sends Commits to some predetermined server. Maybe also create this as a Github Action / Gitlab Action.
Pass a secret (agent + private key) as an env variable
Run the CI workflow whenever wished (e.g. on commit on master)
How do we deal with identifiers here? We could require that all @ids used in the .jsonad are resolvable, but this might ask a lot from the one uploading the file or from the tool / script.
We've also been working on a simpler way to publish atomic data #93. In short, only use local identifiers, and have a clever way of turning these into bigger ones.
Host static JSON-AD files
Basically:
Host a JSON-AD file somewhere, use localId instead of @id.
I'm working on an Importer tool for atomic-server. This can fetch JSON-AD from some URL (in this case, the hosted file somewhere), and then use that internally.
This can be done, for example, with Github pages, or by pointing to the raw files.
However, the resulting @id will point to the server that imported the resource, as only that server is capable of properly hosting the data (i.e. deal with HTTP content negotiation, authorization and more)
@hoijui described a workflow that he'd like to have, where he can modify some Atomic Data (in this case an ontology of Properties and Classes), and have it hosted somewhere + updated when he commits. Seems achievable, but how?
Have a script that posts commits to an atomic server, run as CI step
.jsonad
file in a github repo and sends Commits to some predetermined server. Maybe also create this as a Github Action / Gitlab Action.env
variableHow do we deal with identifiers here? We could require that all
@id
s used in the.jsonad
are resolvable, but this might ask a lot from the one uploading the file or from the tool / script.We've also been working on a simpler way to publish atomic data #93. In short, only use local identifiers, and have a clever way of turning these into bigger ones.
Host static JSON-AD files
Basically:
JSON-AD
file somewhere, uselocalId
instead of@id
.Importer
tool foratomic-server
. This can fetch JSON-AD from some URL (in this case, the hosted file somewhere), and then use that internally.This can be done, for example, with Github pages, or by pointing to the raw files.
See the docs and the #93 issue for more info
However, the resulting
@id
will point to the server that imported the resource, as only that server is capable of properly hosting the data (i.e. deal with HTTP content negotiation, authorization and more)