2b:null 2c:["$","title",null,{"children":"Repository Revision History | James Anderson | Observable"}] 31:T1efc,md` We have now enabled repository revisioning for all Dydra evaluation users on the [dydra.com](http://dydra.com) cloud service. Customers with dedicated and on-site servers will receive this feature in their next scheduled system upgrade. Repository revisioning means that your Dydra repositories maintain revision history that permits read-only access to snapshots of the previous contents of the repository. Every transaction committed (via a SPARQL request or a file import job) on a repository will create a new revision snapshot, enabling you to download and query both the current and previous state of the repository. Further, you can also download the difference between successive revisions to obtain the sets of statements removed and added in the respective transaction. ${await FileAttachment("schema-org-revision.png").image()} As of right now, repository revisioning is supported both in the user interface (a work in progress) as well as more importantly on the level of the various application programming interfaces (APIs) provided by the service. In the user interface, repository owners will now see the current repository revision identifier prominently displayed in the sidebar under the overall repository statistics. As depicted here, Dydra repository revisions are identified by [universally unique identifiers](https://en.wikipedia.org/wiki/Universally_unique_identifier) (UUIDs). This revision UUID is updated on each committed transaction, and is also output as the response [entity tag](https://en.wikipedia.org/wiki/HTTP_ETag) (the HTTP \`ETag\` header) in protocol responses. This affords Dydra applications access to unprecedentedly precise and reliable cache identifiers, the effect of which was already praised in [a recent survey](http://folk.uio.no/kjekje/2015/eswc-2015.html) of the state of the art. On the API level, repositories' SPARQL Protocol and SPARQL Graph Store HTTP Protocol endpoints support a new \`?revision=UUID\` URL parameter that can be used to address a specific previous revision of a repository by specifying its UUID string in this parameter. We are working on updating the API documentation to reflect all this. Note that in the user interface, the repository's current revision identifier serves as a link to the repository's revision history page. For example, the [revision history](http://dydra.com/schema-org-test/schema-org/@history) for the public [schema-org-test/schema-org](http://dydra.com/schema-org-test/schema-org) demo repository hosted at Dydra looks like this: ${await FileAttachment("schema-org-history.png").image()} This repository was created for demonstration purposes from the versioned [Schema.org](http://schema.org) data dumps available at [LOV](http://lov.okfn.org/dataset/lov/vocabs/schema) by additively loading each data dump in a batch script. Each successive transaction loaded a subsequent published version of the ontology; existing statements remained unmodified and new statements were added to the repository, visible from that revision onwards. As mentioned and depicted above, each repository revision is presently publicly identified only by a UUID (which serves as a link to download a snapshot of the repository contents at that revision in [N-Quads](http://www.w3.org/TR/n-quads/) format). We are working on permitting users to store custom provenance metadata that will enable tagging specific revisions with arbitrary string labels. Our previous blog post on [variable SPARQL service locations](http://blog.dydra.com/2015/08/30/variable-service-locations) includes an example of such provenance records. Similarly, users will soon be able to provide a validity timestamp for each revision, helping us to present e.g. ontology history more intelligently than just by the transaction time shown currently. We will elaborate more on this bitemporal aspect of Dydra's revision history in an upcoming blog post. Note that on the revision history screen, the revision statistics to the right-hand side of the UUID indicate not only how many statements were removed and added in that revision, but indeed form a clickable link for downloading a [patch/diff file](https://en.wikipedia.org/wiki/Diff_utility#Unified_format) of that revision in N-Quads format. By downloading [the diff for schema.org version 1.8](http://dydra.com/schema-org-test/schema-org.nq.diff?revision=879ccfcc-52c2-8049-8d43-23772758b8c4) (revision 879ccfcc-52c2-8049-8d43-23772758b8c4 in this repository) we can see that this revision of the ontology added 11 new statements: --- schema-org-test/schema-org.nq (revision 133ac8b1-83b7-ef43-a8ea-c948511402ac) +++ schema-org-test/schema-org.nq (revision 879ccfcc-52c2-8049-8d43-23772758b8c4) + "The CreativeWork encoded by this media object." . + "Indicates a CreativeWork that this CreativeWork is (in some sense) part of." . + . + . + "A media object that encodes this CreativeWork (legacy spelling; see singular form, encoding)." . + "A media object that encodes this CreativeWork. This property is a synonym for encoding." . + "A media object that encodes this CreativeWork. This property is a synonym for associatedMedia." . + . + . + "A WebSite is a set of related web pages and other items typically served from a single web domain and accessible via URLs." . + "WebSite" . --- Speaking for our whole team, we are excited to at long last publicly roll out this major feature. While we haven't previously exposed revisioning to users, Dydra was in fact from the get-go designed and built on a [transactional](https://en.wikipedia.org/wiki/ACID) append-only, [MVCC](https://en.wikipedia.org/wiki/Multiversion_concurrency_control) storage substrate implementing first-class repository revisions. Indeed, the inception of the Dydra concept itself originated directly from our previous research into [bitemporal](https://en.wikipedia.org/wiki/Bitemporal_data) databases and our appreciation for [content-addressable storage](https://en.wikipedia.org/wiki/Content-addressable_storage) as implemented in particular in [Plan 9](https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs) and the Git revision control system. We should note that we haven't as yet settled on an explicit repository revision retention policy for evaluation accounts. That is, while we obviously safeguard the current snaphots of all repositories hosted at [dydra.com](http://dydra.com), we do intend to occasionally garbage-collect superfluous revision history that nobody is making use of. However, in case you do need to retain permanent history for your repository in order to e.g. host an ontology with Dydra, we would be happy to accommodate such a request. If you have thoughts or requests in this regard, we'd welcome any feedback you care to provide. We can be best reached at [info@dydra.com](mailto:info@dydra.com) and [@dydradata](https://twitter.com/dydradata). `32:[{"id":"f3401f51c51159437651a665b629e7b537799f2f1ce8412ab1dd31d0d18f3cf4547007bb2750c8bc0d39e9a9bc190bc4cb9eb3602bebb404f400742a65740c6c","href":"https://static.observableusercontent.com/files/f3401f51c51159437651a665b629e7b537799f2f1ce8412ab1dd31d0d18f3cf4547007bb2750c8bc0d39e9a9bc190bc4cb9eb3602bebb404f400742a65740c6c","name":"schema-org-history.png","type":"image/png","lastModified":1610657175422.592,"size":66259},{"id":"1bcf21eebafee29eb010b453c0e4bae222feadaaf11196f98b3256c95f22262be1e530d0f418ee619b0ba5ce27cf9ab013de1f04c890ae916216e71a06cde27d","href":"https://static.observableusercontent.com/files/1bcf21eebafee29eb010b453c0e4bae222feadaaf11196f98b3256c95f22262be1e530d0f418ee619b0ba5ce27cf9ab013de1f04c890ae916216e71a06cde27d","name":"schema-org-revision.png","type":"image/png","lastModified":1610657184574.733,"size":57266}] 2f:{"id":"b048febdc3ca72fd","slug":"repository-revision-history","title":"Repository Revision History","thumbnail":"fcb2489005b563cf48d36a70c21590f8a1d908152e8bfc9af3f9bd89f3885e09","access_level":"public","create_time":"$D2021-01-14T20:42:32.963Z","update_time":"$D2024-08-10T12:53:24.521Z","view_time":null,"first_public_time":"$D2021-01-14T20:43:32.033Z","fork":false,"stars":0,"starred":false,"owner":{"type":"team","id":"b452fd69977f5701","login":"lomoramic","name":"James Anderson","avatar_url":"https://avatars-next.observableusercontent.com/dc520bbc733259f2913522cf1d50607777b98a3083f290a6f182534561896497","tier":"starter_2024"},"version":19,"publish_version":null,"role":null,"authored":false,"authors":[{"type":"individual","id":"987c90ad70c449c1","login":"lomoramic","name":"James Anderson","avatar_url":"https://avatars-next.observableusercontent.com/dc520bbc733259f2913522cf1d50607777b98a3083f290a6f182534561896497","tier":null}],"members":[{"type":"individual","id":"987c90ad70c449c1","login":"lomoramic","name":"James Anderson","avatar_url":"https://avatars-next.observableusercontent.com/dc520bbc733259f2913522cf1d50607777b98a3083f290a6f182534561896497","tier":null,"role":"editor"}],"comments":[],"custom_thumbnail":false,"trashed":false,"subscribed":null,"forks":0,"collection":null,"type":"notebook","body":{"title":"Repository Revision History","cells":[{"id":0,"value":"md`# Repository Revision History`","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":10,"value":"$31","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"},{"id":6,"value":"import {catalog} from \"@lomoramic/blog-catalog\"","pinned":false,"hidden":false,"mode":"ojs","author":"$undefined","summary":"$undefined"}],"files":"$W32","stdlib":"1","titling":"auto"}} 30:"$2f:body"