Persistence (HowTo)

How to make your Databus Identifiers (more) persistent

Short Version (Best Practice)

1. Databus URIs: When installing a Databus, it is highly recommended to use a subdomain and create an A/AAAA record, e.g. mydatabus.example.com using https. The main rationale behind this is that application will code against the strings of the URIs, which carry the meaning and also resolve to the data. The underlying graph database will be hardcoded against the subdomain you choose initially. If you move the Databus to a different server, all you need to do is update the A/AAAA record. Patterns using paths like https://example.com/databus/ or switching domains later are not recommended (set up and migration will be much more complex).

2. Data: Each dataset metadata record on the Databus contains a link (dcat:downloadUrl) to the actual files. This way applications that are coded against the Databus URIs can access the Databus to resolve Databus file URLs and be redirected to the download locations of the data. This already works in a way similar to DNS, purl.org, DOI, w3id.org and other redirection services. When you move the data, you simply need to update the redirects (either by reposting the records via the HTML interface, the API or by updating the redirects in the database directly). This is part of the Databus design, so that applications still can work, even if data locations change. All metadata edits are logged in the underlying git as part of the G(it|raph) Store.

Details

About persistence