Commutative Replicated Data Types (CRDTs) allow conflcit-free parallelization of editing processes, but provide only limited data structures, whereas application users often have expectations that exceed what CRDTs can provide, for example single editable labels. First, we map out examples and use OWL and non-trivial RDF structures to show where user expectations and available guarantees of conflict-free data structures collide. Second, we present how those apparent conflicts can be exposed to users in an understandable and non-intrusive way using a RDF-aware widget set, and how they can be resolved both by informed users and automatisms.
A a tool for demonstration and potential backend for real application, we show that the git version control system, in its union-merge mode, is an implementation of the SU-Set. The SU-Set semantics are extended to allow some of the constraints of OWL models to hold with conflict-free replication, which allows applications and user experiences to build on their constraints.
… is not written – but I'd like to write it (preferably not alone), and fulfill the promises the abstract makes.
I have not shown the git-SU equivalency, but trust my intuition about it as a working hypothesis: The idea is that a plain N-Triples file configured to the merge model union-merge has practically the same properties.
The OWL semantics transferable into a SU set are about describing rules that say that if an entity (that would typically be a blank node) is inverse-functional on one property and functional on all others, its N-Triples should be written in one line of the .nt file in git. Then, each update on any of its parts is a remove-and-recreate operation, and the functionality of the resource's properties is kept through all merges. This allows expressing struct-like entities as RDF entities with properties rather than model developers cramming the struct into a URN or worse a literal just to have something that's at least internally consistent.
Figure 2 would probably demonstrate how an apparent contradiction: two dates on the "year of birth" property, which is valid in the basic RDF model upheld by SU-Set, but not valid in a user application that expects a single property (possibly backed by an owl:inverseFunctionalProperty). The upper part shows a view for a reader, the lower part shows the interface an editor of the resource is presented.
+-----------------------------------------------------------+
| |
| Epicurus (Philosopher) |
| ---------------------- |
| |
| Year of birth: 341 BCE |
| Year of death: 271 BCE (...) <---+ |
| Writings: Peri Phy+--------------+-----------------+ |
| doxay, Gnomologi| Mouseover on the dots tells | |
| Secondary literatu| the user that there are other | |
| natura deorum, D| values (270 BCE) that are also | |
| philosophorum, C| accepted for this field. | |
| +--------------------------------+ |
+-----------------------------------------------------------+
+-----------------------------------------------------------+
| |
| Editing "Epicurus" (Philosopher) |
| -------------------------------- |
| |
| Year of birth: 341 BCE [+-] |
| Year of death: 271 BCE [set and continue editing] |
| 270 BCE [set and continue editing] |
+-----------------------------------------------------------+
RDF-aware widgets could allow drilling down on the history of a statement;
that's trivial with the git view (basically a git blame file -L line), but
querying that with a SPARQL interface in mind might require queries on reified
statements.
This page is part of chrysn's public personal idea incubator; go up for its other entries, or read about the idea of having an idea incubator for more information on what this is.