inqlab

Glüg

2022-09-30T00:00:00Z

GeoPub: A Multi-Model Database

2022-07-01T00:00:00Z

As part of the openEngiadina project we are researching technology for open and decentralized local knowledge.

Local knowledge comes in a variety of forms and shapes. In order to support this variety we use the RDF data model along with Datalog as a declarative and expressive query laguage (see this previous post).

In this post I'd like to describe the indexing strategies we use that allow efficient querying of local knowledge. In particular, I'd like to highlight how a database can support efficient graph, geo-spatial and full-text search queries at the same time - a multi-modal database. This is an important step towards search and discovery of local knowledge.

Everything described here is implemented in the GeoPub Web application. A demo installation of GeoPub is available here (note that initial loading takes very long).

Without further ado, let's dive into how GeoPub's multi-model database works.

Ordered Key-Value Stores

A very simple form of a database is a key-value store. A key-value store allows values to be persistently stored and accessed with some associated key. Given a key the value can usually be retrieved very efficiently, i.e. in $O (log (n))$ where $n$ is the number of values stored in the database.

Unfortunately, accessing individual values by their keys is not enough to allow interesting database queries.

Assume we have a database with $n$ key-value pairs $(k_{i}, v_{i})$ and some function $f : V \to N$ that maps values to natural numbers. Now we would like to find all the key-value pairs $(k_{i}, v_{i})$ such that $f (v_{i}) = 42$ .

In a simple key-value store there is no way of efficiently finding the subset of key-value pairs that fulfills such a property. We must iterate over all $n$ key-value pairs in the store and evaluate the function on every value individually.

The number of key-value pairs $c$ that we are interested in is usually much smaller than the number of stored key-value pairs $n$ . For example we might be looking for a property that is held by ten entries in a store of millions of entries. In order to be able to query our key-value store efficiently, we really need a way of finding these entries without having to iterate over all entries in the store. Luckily, we don't need to add much to the key-value store. We just need some order.

Order, order!

An ordered key-value store (OKVS) is a persistent storage that allows values to be stored with some associated key. The keys are sorted according to some order and given a range of keys the associated key-value pairs in the range can be accessed efficiently. If there are $c$ key-value pairs in a given range then the complexity of accessing the range is usually $O (log (n) + c)$ . We need to find the first entry in the range ( $O (log (n))$ ) and then iterate over all entries in the range ( $O (c)$ ). This is much better than a simple key-value store.

Note that such a range query can not be implemented efficiently in a simple key-value store. Checking if a key is within a range is a property that must be evaluated on every single stored key-value pair (like our function $f$ ).

But how does this help us query more efficiently?

Pre-Computing Properties

Instead of stroring values associated with the original key, we can instead store them associated with $f (v_{i})$ . The store is now populated with key-values of the form $(f (v_{i}), v_{i})$ .

We can efficiently query for all the values for which $f (v_{i}) = 42$ by querying for the range of keys with $42 \leq k \leq 42$ . In fact we can also query for more interesting ranges: For example all values $v_{i}$ with $13 \leq f (v_{i}) \leq 21$ .

This may seem like a cheap trick, but it is a very powerful way of making values efficiently queryable along some pre-defined properties (in our case the value of the function $f$ ). It is also a very widespread trick. This is what is called an index in database terminology.

The index is a projection of some properties we are interested in to a dimension that can be efficiently queried. In our case the dimension that can be efficiently queried is the intrinsic order of the key-value store. The function $f$ is a projection to this dimension. We will see some more concrete examples that will illustrate this idea much better. Don't worry too much about understanding this in the abstract now.

Of course our toy example is overly simplified and has some draw-backs. For one, we have lost the original keys (the $k_{i}$ ). We also might want to query along some other property (e.g. a function $g$ ). We will be able to solve both with some tricks.

Tuples as Keys

Most existing ordered key-value stores require keys (and values) to be byte sequences and the intrinsic order in which keys are sorted is the lexicographic byte order. That is b00 < b01 and b0 < b00.

We can use other types such as bools, integers, strings or compound types for keys as long as we can encode them to bytes. The only thing we must ensure is that the encoding preserves the order between keys.

We will mostly be using tuples as keys. For example a key could be $(1, 2, 3)$ or $(Lorem Ipsum, true, 32)$ . We use lexicographic order on tuples, e.g. $(1) < (1, 2) < (1, 5) < (42) < (strings are ordered higher than ints, 52)$ .

The fact that an order preserving encoding to byte sequences exists for tuples (and the types we use in tuples) is left as an exercise for the reader. Hint: For tuples try a concatenation of type-length-value encoded elements (e.g. CBOR).

Another basic type that will be useful is symbols. We will use symbols such as rdf or spo in key tuples, e.g.: $(rdf, spo, 1, 42, 98)$ .

Using symbols allows us to create named sub-spaces that can be queried efficiently. For example we can efficiently query for all keys in the $(rdf, spo)$ space that start with the values 1 to 12 by querying for the range of keys with $(rdf, spo, 1) \leq k \leq (rdf, spo, 12)$ . This would return keys such as $(rdf, spo, 1, 42, 98)$ , $(rdf, spo, 1, 59, 2)$ or $(rdf, spo, 7, 8, 5)$ (if present in the store).

Indexing

We are now ready to improve on our initial solutions for efficiently querying values applied to the function $f$ .

To recap: we have a bunch of key-value pairs $(k_{i}, v_{i})$ , a function $f : V \to N$ that maps values to natural numbers and we would like to find key-value pairs for which the applied function takes on some values.

For every key-value pair $(k_{i}, v_{i})$ that we store, we also store an additional entry with key $(f, f (v_{i}))$ and value $k_{i}$ .

In order to efficiently query along the property defined by the function $f$ we query for all keys in the range $(f, lower-bound) \leq k \leq (f, upper-bound)$ . The values returned by this query are the original keys $k_{i}$ . We can use them to retrieve the associated values $v_{i}$ .

The additional entries $(f, f (v_{i}))$ are index entries that point to the original key (also called the primary key). Unlike our initial solution we have not lost any information and can easily add additional indexes for other properties.

This is the basic idea towards building your own custom indices and multi-model databases. We will see examples and variations of this idea when looking at concrete examples below.

Implementation Notes

Ordered-key value stores such as LMDB or LevelDB expose an API as described above and the ideas illustrated above can be implemented pretty directly. In GeoPub we use the web-native database IndexedDB, which provides a slightly different and more high-level API. Nevertheless, the OKVS ideas can be applied and we will give some hints on how while discussing the examples. For a deep-dive check out the GeoPub source-code.

Indexing Strategies

Enough of the abstract. Let's look at some concrete examples of properties and dimensions on which we would like to be able to efficiently query.

RDF Triples

For the openEngiadina project we use the RDF data model to support the various types of data (see this previous post for an introduction to RDF).

In a nutshell: In RDF data is represented as a directed and labeled graph. Nodes are either IRIs (internationalized URIs) or literal values and directed edges are labeled with an URI. The atomic elements in RDF are triples: two nodes and the directed edge between them. Or in RDF parlance: A subject node that is connected with a directed edge, that is labeled with a predicate, to an object node.

We will use the notation $(s, p, o)$ for triples, where $s$ is the subject, $p$ the predicate and $o$ the object. A value that may appear in the subject, predicate or object position of a triple is called a term.

We note that in RDF things and concepts ideally have unique identifiers. Even if they appear in completely different contexts. In other word, the same term can appear in many triples.

Dictionary

Reflecting on the fact that terms are heavily re-used in RDF, we make them primary entities in our database.

For every term $t$ appearing in some RDF graph, we create an unique identifier $id$ and add an entry with key $(dictionary, id)$ and value $t$ .

Triple Indices

We now have stored all the terms that appear in our RDF data. We are still missing the triples. How do we represent triples in our ordered key-value store?

Given some term $s$ we might be interested in all the triples where $s$ appears as subject. To answer this query we could add entries with key $s$ and value $[(p_{1}, o_{1}), (p_{2}, o_{2}), ...]$ such that $(s, p_{i}, o_{i})$ are triples.

This is a complete representation of all triples, i.e. we have stored the RDF graph. However, this does not seem like a very good representation. For every new triple we add to our database we need to modify some stored values, which is usually more expensive than adding new smaller entries. Furthermore, we are not making good use of our ordered key-value store. To query for all objects that appear in triples with some fixed subject and predicate we need to find the entry, unpack the value and filter the stored list. We can do better.

Instead let's add entries with keys $(s, p_{i})$ and values $[o_{1}, o_{2}, ...]$ such that $(s, p_{i}, o_{i})$ are triples. Already better! We can now do a range query to find all triples for a given subject $s$ , i.e. by querying for all keys with $(s) \leq k \leq (s)$ we will get all matching keys and can unpack the objects of the triple.

We can apply this trick once more and for every triple add an entry with key $(s, p, o)$ and an empty value. Now querying for all triples given a fixed subject and predicate is simply a range query. Adding a new triple is also just creating a new entry.

But what if we want to query for all triples with a fixed object? Our $spo$ index is of no use here. We can not do a range query that binds the object as the lexicographical order of the index is wrong. Luckily, we can easily add another index to be able to efficiently perform such queries, e.g. an $osp$ index.

It turns out that to efficiently query RDF triples in any direction we only need three indices: $spo$ , $pos$ and $osp$ . This is a very nice argument in favor of RDF. The simple structure of the data model allows efficient indexing and querying while still being very expressive. The same argument has been made previously by Weiss et. al. (see Hexastore: Sextuple Indexing for Semantic Web Data Management), where they show that six indices are enough to query RDF efficiently. By using ordered key-value stores we can improve on this and only need three indices.

The Index is the Massage

You might have noticed that the dictionary is not really necessary. We could populate our indices with the RDF terms directly. Using a dictionary is a considerable performance improvement and allows us to follow the framework of indices being projections of some values.

The $spo$ , $pos$ and $osp$ indices may be seen as projections of the RDF terms. The projection is just dependent on the RDF graph. The projection, or the index, is really the content we are interested in.

Alternatively, you may see the RDF graph as a set of triples and our indices as a method for querying set membership efficiently. This is probably a more direct way of reasoning, but would not allow us to make cool puns.

GeoPub Implementation Notes

IndexedDB does not allow the manual creation of indices. We need to use a little trick.

We create an ObjectStore triples, where for every triple we add a JavaScript object with three fields corresponding to the indices:

{"spo":[6,8,9],"pos":[8,9,6],"osp":[9,6,8]}

We create IndexedDB indices that index the respective fields and can now query triples efficiently.

Note that the integers are the identifiers for the terms as stored in the dictionary and that IndexedDB orders arrays exactly how we would like tuples to be ordered (see the relevant section of the IndexedDB specification). This allows us to use range queries to find matching triples, as described above.

Geo-Spatial

There are some limits to what we can query for with the RDF indices presented previously. For example some RDF data might have geo-spatial information attached:

<https://example.com/a-geo-note>
  a as:Note ;
  geo:lat "46.7970040956";
  geo:long "10.2982868244";
  as:content "An ActivityStreams note with a geo position." .

We would like to be able to find such notes efficiently by querying for things in the vicinity of a given point.

Note that we can not do this with the RDF indices as described above. The RDF indices only allow us to search for triples that exactly match some pattern. Finding things in the vicinity can not be formulated as a triple pattern that should be matched. We need a specialized index.

Geo-spatial data is two dimensional and we need to be able to query both dimensions (longitude and latitude) at the same time. There exist specialized data-structures for querying such multi-dimensional data. Examples include Quadtrees, R-Trees or k-d trees. Our ordered key-value store, on the other hand, is queryable only in a single dimension. Can we still make use of our okvs for geo-spatial queries?

Z-Order Curve and Geohash

The trick is to project the multi-dimensional data to a single dimension while preserving locality of points. If two points are close together in the higher dimension their projection to the single dimension should also be close together (and vice-versa). We will use a Z-order curve that fulfills these properties (almost).

A Z-order curve partitions a two dimensional space by filling the space with "Z"s. At every iteration the curve is repeated (like a fractal) to more finely fill the space and allow higher resolution. A popular implementation of a Z-order curve is Geohash. We will use Geohash for our geo-spatial index.

Geohash maps an area bounded by latitude and longitude to a sequence of characters. The more characters used the more precise the resolution - the smaller the area. With enough precision the areas become good approximations for points.

For example the position of the ActivityStreams note can be described with the Geohash u0r64r4ur3z4. Whereas the Geohash u0r6 roughly describes the area of the lower Engadin valley (about 20 sqkm). Note that the larger area is a prefix of the more precise Geohash. This is something we can efficiently query for with our ordered-key value store.

Geohash index

For every RDF subject with geo-location we add an entry with key $(geo, Geohash (lat, long))$ and value the identifier of the RDF subject.

To query for subjects in a certain area we compute the Geohash of the area and then query for all entries in the geo index that start with the Geohash of the area. This can be formulated as a range query on an ordered key-value store.

Using Geohash has some limitations: It does not in general hold that two points that are geo-graphically close are close together in the Geohash projection (the opposite does hold). In particular this happens close to borders where Geohash splits the space. Mitigations are known and can be implemented (see the notes in the Wikipedia).

Full-Text Search

Another dimension we would like to be able to query is full-text, i.e. given some natural language term we would like to find all entries that contain the term. This is another example of where exact RDF triple pattern matching does not work.

Full-text search is a fuzzy thing. It would be nice if a query for the term "connected" also returns entries that contain the words "connections", "connected" or "connective". This can be done by performing a linguistic normalization called stemming (see the Xapian documentation for a good introduction to the topic).

In order to perform full-text searches we create an index for all RDF literals that have type string (and langString) that maps the linguistic normalized stems appearing in the literal to the literal identifier (as stored in the dictionary).

When given a query we again perform the linguistic normalization on the query to first get a list of query stems. We then use the index to find all literals that contain the stems appearing in the query.

When querying we want to match literals that contain all the query stems (i.e. query result should be a logical and, not a logical or). This is a join over the literal ids. A neat trick (that we stole from this little gist) is to do this join as a merge join. This is an efficient join algorithm that uses the fact that entries are soreted in the okvs.

More Indices

We have looked at three different indexing strategies (RDF, geo-spatial and full-text search) that can be implemented on ordered key-value stores. There are more indices that can be implemented on ordered key-value stores. Examples include temporal indices, pre-computed cryptographic signature verification (see RDF Signify and DMC), revisions (i.e. versioning) and many more!

Conclusion and Outlook

I hope to have illustrated the ideas behind how we have implemented a multi-modal database for openEngiadina that is capable of handling the variety of data that is local knowledge.

The main ingredient to all this has been ordered key-value stores. I find this a very elegant and powerful abstraction. The ideas are practically accessible as robust and well-tested ordered key-value stores exist (e.g. LMDB, LevelDB or SQLite LSM) that can be used to experiment with the ideas. The hard parts of databases (persistence and transactions) are already solved and we can experiment with indices and how to make concrete queries efficient in relative safety.

Ordered key-value stores are a relatively niche subject. Previous work include SRFI-167 and SRFI-168 by Amirouche Boubekki as well as FoundationDB.

This post is a feeble attempt to provide a framework for thinking about ordered key-value stores. I hope to have sparked your interest and invite you to experiment and formulate your thoughts on the topic. Much more thought and work is needed to polish these ideas.

SPARQL and GeoSPARQL

SPARQL is a query language for RDF databases. The ideas described in this post can be used to implement a SPARQL query engine - they describe lower-level indexing strategies.

I do hope to have motivated the case for application specific indices. Some applications may require geo-spatial indexing, others may requires high-performance indexing of revisions or pre-computed cryptographic functions.There are extensions to SPARQL that allow geo-spatial indexing (GeoSPARQL) and also vendor-specific extensions that allow full-text search. However, I believe that SPARQL is in general not flexible enough to allow such extensions and application specific optimizations.

Datalog

As mentioned in a previous post we use Datalog as query language. Datalog naturally allows custom indexing strategies and the formulation of queries that make use of them. I hope to motivate these ideas in a future post.

Fin

My fellow openEngiadina developer rustra has been sentenced to 5 years in prison as a victim of political repression in Belarus. Read his last words in court and an interview. Please consider donating to the Anarchist Black Cross Belarus.

Many thanks to the countless people who have helped form these ideas and have provided valuable feedback and ideas. A special thanks goes to Amirouche Boubekki who gave me the courage to pursue these ideas with his work on SRFI-167, SRFI-168 and Babelia.

Thank you, dear reader, for your interest and time. If you have thoughts, comments or questions, please feel free to get in contact! We have an IRC room on Libera (#openEngiadina) or you can contact me directly by mail (pukkamustard [at] posteo [dot] net).

The openEngiadina project is supported by the NLnet Foundation trough the NGI0 Discovery Fund.

GeoPub: Datalog, RDF and IndexedDB

2022-04-14T00:00:00Z

As part of the openEngiadina project we are researching a semantic social network - a system for creating and sharing complex data. Our approach includes:

RDF to support the various types of data.
Content-addressing to make content robustly available.
The ActivityStreams vocabulary to describe social interactions on data.
XMPP as a federated transport protocol.

This approach is being tested in a proof-of-concept Web application: GeoPub. I am very happy to announce a new release of GeoPub (v0.5.0) that uses the query language Datalog and the Web-native database IndexedDB. This is a significant step towards decentralized and local-first applications for local knowledge.

A demo installation of GeoPub is available here (Please note that initial loading of GeoPub can take some time as sample data and vocabularies are loaded. Subsequent reloads should be much faster.)

In this post I'd like to give a brief overview of Datalog, how it is used in GeoPub and with IndexedDB.

Datalog

Datalog is database query language based on logic programming. In a nutshell it allows you to describe entailment rules which allow complex facts to be derived from more simple facts. Such rules form a Datalog program.

For example a program that computes the existence of paths from simple edges:

path(a,b) :- edge(a,b).
path(a,b) :- edge(a,c), path(c,b).

The program consists of two rules (or clauses) that define when path holds. Here path(a,b) holds if there is a direct edge between a and b or if there is an intermediary node c that connects a and b (the second rule). The terms a, b and c are variables that can be bound to any matching values. Given some database that stores the simple edge facts, this Datalog program can compute the transitive closure - i.e. all paths appearing in the graph of nodes connected with edges.

People familiar with Prolog will recognize the syntax of the program above, it is very similar to Prolog. However the semantics - the meaning - of a Datalog program is defined differently than for a Prolog program. Datalog turns out to be much better suited for querying databases. For example queries are guaranteed to terminate. On the other hand Datalog programs are strictly less expressive than Prolog programs. Datalog is not Turing-complete.

For a more in-depth introduction to Datalog I can highly recommend the paper What You Always Wanted to Know About Datalog (And Never Dared to Ask) (1989) or chapters 12 and 13 of Foundations of Databases (the Alice book). I have also given a talk on the topic: Logic Programming and Databases (2021).

Datalog and RDF

Given a database that stores RDF triples as triple(subject, predicate, object) we can query the triples using Datalog.

For example the Datalog predicate note defined by

note(s) :- triple(s, <rdf:type>, <as:Note>).

can be used to query for all objects that have type <as:Note> (placeholder for https://www.w3.org/ns/activitystreams#Note).

We may define other predicates:

content(c) :- note(s), triple(s, <as:content>, c).
withGeo(s) :- triple(s, <geo:lat>, lat), triple(s, <geo:long>, long).

The predicate content returns the content of all notes and withGeo holds if something has a latitude and longitude attached.

The usual way to query RDF is with SPARQL. There are many reasons why I think that Datalog is a much better query language:

Datalog is a much simpler language. If you have been able to follow the examples given above, then you already understand the entire syntax of Datalog.
Datalog allows recursive queries. SPARQL allows a form of recursion via property paths, however this is very limited (see Recursion in SPARQL).
Datalog can be extended with built-in predicates that perform arbitrary computation. This allows unpacking complex literal values for use in specialized indices (e.g. geospatial coordinates or full-text search) or computation of cryptographic functions during query evaluation (e.g. DMC). There are numerous SPARQL extensions that add similar functionalities, but they all require additional syntax and custom implementations.
There is a rich literature on how to optimize Datalog queries and many existing and historic applications on massive amounts of data.
Datalog programs compose naturally. Did you notice that content is defined by using the previously defined note predicate? This almost uncanny composability is a intrinsic feature of logic programming. See for example William Byrd's talk at FOSSDEM 2021 to see how nice this is.

Finally, Datalog can be implemented with reasonable effort. See the stand-alone OCaml implementation that we developed for openEngiadina: ocaml-datalogl.

Type Inference

Another huge advantage of Datalog over SPARQL is the ability to express complex inference rules.

For example RDF Schema defines a vocabulary for RDF classes and properties. This is used in vocabularies such as ActivityStreams that define classes and properties as such:

@prefix as: <https://www.w3.org/ns/activitystreams#> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

as:Create a owl:Class ;
  rdfs:label "Create"@en ;
  rdfs:subClassOf as:Activity ;
  rdfs:comment "To Create Something"@en .

as:Like a owl:Class ;
  rdfs:label "Like"@en ;
  rdfs:subClassOf as:Activity ;
  rdfs:comment "To Like Something"@en .

The as:Create and as:Like classes are defined as sub-classes of as:Activity (using the rdfs:subClassOf property).

Real data is usually annotated with the most concrete and specific type:

@prefix ex: <https://example.com/> .

ex:activity1 a as:Create ;
  as:actor ex:actor .

ex:activity2 a as:Like;
  as:actor ex:actor2 .

Here ex:activity1 and ex:activity2 are specified to have class as:Create and as:Like respectively. This is how one usually encounters content on ActivityPub.

Sometimes we might only be interested in finding all activities (class as:Activity) regardless of the specific sub-class. Can we formulate a query that does this? With Datalog, yes:

rhodf(x, <rdf:type>, b) :- triple(a, <rdfs:subClassOf>, b), triple(x, <rdf:type>, a).

The predicate rhodf(x, <rdf:type>, b) (x has type b) holds if a is a sub-class of b and x has type a.

A query rhodf(x, <rdf:type>, <as:Activity>) will return all x that have the type of any sub-class of as:Activity. Exactly what we want.

Such inference rules are an important tool in being able to deal with a wide (and extensible) variety of data. We have implemented inference rules as described in Simple and Efficient Minimal RDFS (2009) in GeoPub.

IndexedDB

IndexedDB is a Web API that allows large amounts of content to be stored at client-side (i.e. in the browser). GeoPub now uses IndexedDB to store content. Datalog evaluation is performed directly on IndexedDB without having to first load the entire database to memory.

Content can be viewed and inspected locally (without any XMPP connectivity). It's still a long way to make GeoPub usable without any internet connectivity, but by using IndexedDB we have made a significant step towards being local-first.

I invite you to inspect the GeoPub database via the development tools in your browser (Firefox: "Storage" > "IndexedDB", Chromium: "Application" > "Storage" > IndexedDB"). By maintaining appropriate indices we are able to perform arbitrary queries efficiently.

Next Steps

This milestone is an important technical proof-of-concept. Much work is required in terms of usability. This will be the focus of the next GeoPub milestone where we hopefully will also be able to showcase some interesting use-cases based on the Valueflows vocabulary.

There is much room for improving the performance of IndexedDB and the Datalog implementation.

The openEngiadina project is slowly winding down and finishing up last milestones as part of the NLnet/NGI0 funding. Feel free to join our chat to stay up to date (via IRC or Matrix).

In the meantime we have secured funding for continuing the development of ERIS - a scheme for robust content-addressing and a spin-off from the openEngiadina project. Stay tuned for updates and feel free to join our mailing list.

Fin

It saddens me deeply to have to say that my fellow openEngiadina developer rustra is still under arrest in Belarus. Resist political repression and support the victims! Please consider donating to the Anarchist Black Cross Belarus or showing your support in any other way.

I look forward to questions and comments via mail (pukkamustard [at] posteo [dot] net). Thank you for your interest and keep safe!

The openEngiadina projects is supported by the NLnet Foundation trough the NGI0 Discovery Fund.

Die Erklärung

2022-02-22T00:00:00Z

Edle und respektierte Bürger Zürichs, Studenten, Handwerker, Arbeiter, Vagabunden, Ziellose aller Länder, vereinigt euch. Im Namen des Cabaret Voltaire und meines Freundes Hugo Ball, dem Gründer und Leiter dieses hochgelerten Institutes, habe ich heute abend eine Erklärung abzugeben, die Sie erschüttern wird.

Ich hoffe, dass Ihnen kein körperliches Unheil widerfahren wird, aber was wir Ihnen jetzt zu sagen habe, wird Sie wie eine Kugel treffen. Wir haben beschlossen, unsere mannigfaltigen Tätigkeiten unter dem Namen Dada zusammenzufassen. Wir fanden Dada, wir sind Dada, und wir haben Dada.

Dada wurde in einem Lexikon gefunden, es bedeutet nichts. Dies ist das bedeutende Nichts, an dem nichts etwas bedeutet. Wir wollen die Welt mit Nichts ändern, wir wollen die Dichtung und Malerei mit Nichts ändern und wir wollen den Krieg mit Nichts zu Ende bringen.

Wir stehen hier ohne Absicht, wir haben nicht mal die Absicht Sie zu unterhalten oder zu amüsieren. Obwohl dies alles so ist, wie es ist, in dem es nämlich nicht ist, brauchen wir dennoch nicht als Feinde zu enden. Im Augenblick, wo Sie unter Überwindung Ihrer bürgerlichen Widerstände mit uns Dada auf ihre Fahne schreiben, sind wir wieder einig und die besten Freunde. Nehmen Sie bitte Dada von uns als Geschenk an, denn wer es nicht annimmt, ist verloren. Dada ist die beste Medizin und verhilft zu einer glücklichen Ehe. Ihre Kindeskinder werden es Ihnen danken.

Ich verabschiede mich nun mit einem Dadagruss und einer Dadaverbeugung. Es lebe Dada. Dada, Dada, Dada.

ActivityStreams over XMPP

2022-01-17T12:00:00Z

ActivityPub is a federated protocol for social networking that is used by projects such as Pleroma, PeerTube, Mobilizon or Mastadon (and many more).

ActivityPub can be seen as a HTTP based protocol for sending around pieces of information that describe interactions by and between actors. An interaction might be the act of creating a post addressed to some audience, commenting on a post or forwarding a post. These interactions, or activities, are described using the ActivityStreams Vocabulary serialized as JSON-LD.

The openEngiadina project is researching a semantic social network - a system for creating and sharing complex data. As previously mentioned we have shifted from using ActivityPub to XMPP as a protocol for sending around pieces of information. We still use the ActivityStreams vocabulary for describing social interactions.

In this post I'd like to describe how ActivityStreams can be used over XMPP, how we have implemented this in openEngiadina and how a bridge between ActivityPub and XMPP might work.

ActivityStreams as an RDF Vocabulary

The ActivityStreams vocabulary defines types (e.g. Activity, Create or Person), properties (e.g. actor or to), rules how they may be combined as well as their meaning. The vocabulary is defined primarily for usage in JSON documents, or more specifically JSON-LD. The examples in the ActivityStreams specification use JSON and so does ActivityPub.

However, this is not the only way you can use the the ActivityStreams vocabulary. The ActivityStreams vocabulary is also provided as an RDF vocabulary. This allows terms to be used from any RDF data, combined with other existing RDF vocabularies and serialized with formats other than JSON-LD. For example a Create activity might be serialized to RDF/Turtle:

@prefix as: <https://www.w3.org/ns/activitystreams#> .

<urn:uuid:9282e9cc-14d0-42b3-a758-d6aeca6c876b>
    a as:Create ;
    as:object <urn:uuid:d18c55d4-8a63-4181-9745-4e6cf7938fa1> ;
    as:to <https://social.example/alyssa/followers/> .

<urn:uuid:d18c55d4-8a63-4181-9745-4e6cf7938fa1> 
    a as:Note ;
    content: "Turtles all the way down." .

RDF in XML's clothing

Another serialization of RDF is RDF/XML - a serialization of RDF into XML. An ActivityStreams Activity can be serialized to RDF/XML as such:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:as="http://www.w3.org/ns/activitystreams#">

  <rdf:Description rdf:about="urn:uuid:9282e9cc-14d0-42b3-a758-d6aeca6c876b">
    <rdf:type rdf:resource="http://www.w3.org/ns/activitystreams#Create"/>
    <as:object rdf:resource="urn:uuid:d18c55d4-8a63-4181-9745-4e6cf7938fa1"/>
    <as:to rdf:resource="https://social.example/alyssa/followers/"/>
  </rdf:Description>

  <rdf:Description rdf:about="urn:uuid:fd18c55d4-8a63-4181-9745-4e6cf7938fa1">
    <rdf:type rdf:resource="http://www.w3.org/ns/activitystreams#Note"/>
    <as:content> XML, oh XML.</as:content>
  </rdf:Description>

</rdf:RDF>

Beautiful, eh?

XML might not be nice and using it as a serialization of RDF is maybe not the best idea. But it works and we can use this to transport ActivityStreams over XMPP.

XEP-0277, Atom and ActivityStreams

As mentioned in a previous post, there is an XMPP extension that allows XMPP to be used for microblogging (XEP-0277: Microblogging over XMPP). The idea is to use the Atom Syndication Format (a XML format) and publish posts on a dedicated node that is attached to a XMPP user (see XEP-0163: Personal Eventing Protocol).

A simple post might look like this:

<entry xmlns='http://www.w3.org/2005/Atom'>
  <title type='text'>hanging out at the Caf&amp;#233; Napolitano</title>
  <id>tag:montague.lit,2008-05-08:posts-1cb57d9c-1c46-11dd-838c-001143d5d5db</id>
  <published>2008-05-08T18:30:02Z</published>
  <updated>2008-05-08T18:30:02Z</updated>
</entry>

Posts of this form are supported by XMPP clients such as Movim and Libervia. When transported over HTTP this format is supported by countless feed aggregators.

We can embed the ActivityStreams activity into an Atom entry by using the RDF/XML serialization:

<entry xmlns="http://www.w3.org/2005/Atom">
  <title type="text">An ActivityStreams Post</title>
  <author>
      <name>Alyssa</name>
      <uri>xmpp:[email protected]</uri>
  </author>
  <id>urn:uuid:9282e9cc-14d0-42b3-a758-d6aeca6c876b</id>
  <updated>2021-01-16T18:28:00Z</updated>
  <content type="application/rdf+xml">
    <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
        xmlns:as="http://www.w3.org/ns/activitystreams#">

    <rdf:Description rdf:about="urn:uuid:9282e9cc-14d0-42b3-a758-d6aeca6c876b">
        <rdf:type rdf:resource="http://www.w3.org/ns/activitystreams#Create"/>
        <as:object rdf:resource="urn:uuid:d18c55d4-8a63-4181-9745-4e6cf7938fa1"/>
        <as:to rdf:resource="https://social.example/alyssa/followers/"/>
    </rdf:Description>

    <rdf:Description rdf:about="urn:uuid:fd18c55d4-8a63-4181-9745-4e6cf7938fa1">
        <rdf:type rdf:resource="http://www.w3.org/ns/activitystreams#Note"/>
        <as:content> XML, oh XML.</as:content>
    </rdf:Description>

    </rdf:RDF>
  </content>
  <link rel="alternate" type=application/json+ld">
      https://social.example/post/0/json-ld
  </link>
</entry>

This is (as far as I understand) a fully compliant Atom entry. Such an embedding would allow us to publish ActivityStreams on XMPP (via XEP-0277). More generally, this can be used to publish ActivityStreams to any Atom feed aggregator (over HTTP).

However, there are some disadvantages:

An Atom entry requires certain fields to be present (e.g. author, title). For some of these (e.g. author) it seems very straighforward to extract from the ActivityStreams objects. For others, in particular the title field, it's tricky. For a reliable embedding one would need to find a good heuristic for finding a meaningful title from arbirtary content.
In order to understand the content of such an Atom entry, one has to parse and use the RDF/XML content.

Interestingly, the first version of ActivityStreams, that was published in 2011, was defined as an embedding into - you guessed it - Atom (Atom Activity Streams 1.0). Later in 2011 JSON Activity Streams 1.0 was released where ActivityStreams are embedded into JSON. This is then developed into ActivityStreams 2.0, which uses JSON-LD. By using the RDF backdoor of JSON-LD and serializing to RDF/XML we have gone full circle back to Atom in a decade. I wonder what we will be doing in 2032?

A dedicated PEP node

While the embedding of ActivityStreams in Atom is interesting, it does not seem to be very practical. Existing feed readers or XMPP clients that implement XEP-0277 would not be able to parse and understand the RDF/XML content.

For openEngiadina, the ability to use RDF is very important for being able to expressing the multitude of different contents we would like to be able to handle. Supporting RDF is a core tenet and carrying around an RDF/XML parser is a necessary burden. The only benefit of fitting RDF content into Atom posts would have been interoperability with XEP-0277 and feed aggregators. This is not possible, so we might as well not bother with using Atom.

XEP-0163: Personal Eventing Protocol is an XMPP extensions that allows XMPP Publish-subscribe nodes to be attached directly to XMPP users (PEP nodes). Nodes are named and users can create as many as they like. The XMPP extension for microblogging (XEP-0277) uses the name urn:xmpp:microblog:0 for its PEP nodes. Other services use different names (e.g. org.salut-a-toi.event:0 is used for events in Libervia).

In the latest version of GeoPub we have started using the PEP nodes with name net.openengiadina.xmpp.activitystreams for publishing ActivityStreams. ActivityStreams objects are formated as RDF/XML and published as is without any further wrapping.

When publishing some ActivityStreams following XMPP IQ is sent:

<iq xmlns="jabber:client" id="f800e0f4-b178-4bcc-964e-3ffdd5f8d680" 
    type="set" 
    from="[email protected]/WCHe5clN" 
    to="[email protected]">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <publish node="net.openengiadina.xmpp.activitystreams">
      <item id="urn:uuid:82c73927-22bb-4fbd-8816-9eb8b63e7990">
        <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
                 xmlns:as="http://www.w3.org/ns/activitystreams#" 
                 xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#">
          <rdf:Description rdf:about="urn:uuid:195096cc-fbf1-45b2-8573-696502871116">
            <rdf:type rdf:resource="http://www.w3.org/ns/activitystreams#Note"/>
            <as:content>
              Hello from GeoPub!
            </as:content>
          </rdf:Description>
          <rdf:Description rdf:about="urn:uuid:82c73927-22bb-4fbd-8816-9eb8b63e7990">
            <rdf:type rdf:resource="http://www.w3.org/ns/activitystreams#Create"/>
            <as:actor rdf:resource="xmpp:[email protected]"/>
            <as:object rdf:resource="urn:uuid:195096cc-fbf1-45b2-8573-696502871116"/>
            <as:published rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">
              2022-01-17T10:16:41-00:00
            </as:published>
          </rdf:Description>
        </rdf:RDF>
      </item>
    </publish>

Users who are subscribed to the PEP node will then get the ActivityStreams activity pushed to them in an XMPP message.

What is nice about this PEP node is that it is not bound to microblogging. This node can be used to share short notes, events, music, videos, OpenStreetMap edits, tasks in a ticketing system or any other structured data and also the interconnections between these pieces of data. ActivityStreams is used as a vocabulary to frame these interactions (similar to how Atom is used).

If you would like to try this you can use GeoPub version 0.4.0. A demo installation is available here.

In the future this might be documented as a proper XEP and it we might use the urn:xmpp:activitystreams:0 name for nodes. For now we will experiment with this from openEngiadina and try to gain some experience.

Bridge between ActivityPub and XMPP

By just using a different RDF serialization of ActivityStreams we have a very high level of interoperability. To create a bridge between ActivityPub and XMPP we just convert the content from RDF/XML to JSON-LD. This conversion is lossless, in the sense that the content itself (i.e. in the RDF data model) remains exactly the same. It is just a conversion between two serialization formats.

Granted, this is not an easy conversion. It requires parsing RDF/XML, serializing to JSON-LD (while using the JSON-LD Framing Algorithms to make sure it is in a form expected by ActivityPub) and vice-versa. But it is in principle possible and can be done in more central places, without requiring clients to carry around both serializations. For programming languages such as Python or JavaScript libraries exist for handling both serialization formats.

Another aspect, which I have completely ignored, is addressing. A bridge between ActivityPub and XMPP would also need to make sure content is sent to the right place. The Libervia project is currently working on this and I look forward to interoperability beyond protocols that this might allow.

Next Steps

Now that RDF content can be sent over XMPP we would like to explore ideas on how to make the content discoverable and easier to interact with by quering and infering. Stay tuned!

Fin

My fellow openEngiadina developer rustra is still under arrest in Belarus. Resist political repression and support the victims! Please consider donating to the Anarchist Black Cross Belarus.

Thank you for making it so far and thank you very much for your interest! Thanks also to the kind people at [email protected]?join">[email protected] for the nice historical trivia on ActivityStreams in Atom and to Jos van der Oever for the interesting discussions.

Please get in touch by mail (pukkamustard [at] posteo [dot] net) or by joining the openEngiadina chat (via IRC or Matrix).

The openEngiadina projects is supported by the NLnet Foundation trough the NGI0 Discovery Fund.

Oh Susanna

2021-12-17T00:00:00Z

openEngiadina: From ActivityPub to XMPP

2021-11-12T00:00:00Z

The openEngiadina project is developing a platform for open local knowledge. With regard to technology, this has so far consisted of:

Research into a suitable data model:
- How to use RDF for various types of data (including ActivityStreams for social interactions)
- How to make RDF content-addressable
- A scheme for robust content-addressing
- How to cryptographically sign content-addressed content
- How to use CRDTs for mutability (this work has been continued as part of the DREAM project)
Development of a client for creating and curating content: GeoPub
Development of a server capable of handling of such diverse types of content: CPub

The network protocol we have been using is ActivityPub. This seemed to be a perfect fit. We believe that managing knowledge is a social activity and ActivityPub is primarily a protocol for social interactions. Furthermore, ActivityPub can be extended to allow arbitrary RDF content via the JSON-LD serialization.

Unfortunately, we have come to realize that using ActivityPub is considerably harder than we expected:

Using JSON-LD as an RDF serialization is very complicated. It requires the usage of algorithms (e.g. the Expansion Algorithm or the Framing Algorithm) that are quite difficult to understand and implement. This complexity seems to come from the desire to bridge Linked Data ideas to JSON in such a way that people familiar with JSON are not intimidated. For people who care more about the Semantic Web aspects and are not tied to using JSON, the additional complexity of having to use the JSON-LD algorithms is considerable. JSON-LD maybe was really just not intended to be an RDF serialization and trying to use it as such is painful.
There are not many implementations of the ActivityPub Client-to-Server protocol (C2S). This made developing and testing the client and server more time-consuming as we had to develop the protocol in lockstep on client and server. At the end we were still only compatible with our own software.
ActivityPub is not a complete specification and many additional protocols need to be implemented (e.g. WebFinger) in specific ways in order to be compatible with existing servers.

Over the last couple of months we have been exploring XMPP as an alternative to ActivityPub and are happy to announce an initial proof-of-concept version of GeoPub - the openEngiadina client - using XMPP. You can try it here (an XMPP account is required). The source code is available on Codeberg.

In the following I'd like to outline how XMPP works in the context of openEngiadina and sketch the next steps we are thinking of.

Update (2021-11-23): Changed wording in paragraph on JSON-LD to prevent it from being missunderstood as an argumentum ad hominem.

Update (2021-12-02): Changed wording in paragraph about there being practically no implementation of C2S protocol. There are a few. See this post on SocialHub.

XMPP for Open Local Knowledge

XMPP (Extensible Messaging and Presence Protocol) is a protocol for instant messaging but as the name indicates it is extensible and can be used for way more applications.

Similar to ActivityPub, XMPP is a federated protocol where clients connect to servers of their choice that interoperate and can exchange messages.

The core protocol is defined in an IETF RFC: RFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core. Another document describes how the core protocol can be used for instant messaging: RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence.

Further extensions are maintained by the XMPP Standards Foundation as XEPs (XMPP Extension Protocols). There are currently over 400 XEPs describing various extensions. However, it is not necessary to implement all XEPs in order to have a working XMPP client/server. The core RFC is enough to start communicating and with a handful of XEPs you can build a working application. The Modern XMPP project maintains recommendations for which XEPs to implement for which use-cases.

Publish-Subscribe

XMPP is most widely used for instant messaging (as in chatting) but it can be used to develop way more types of applications via the publish-subscribe pattern as described by XEP-0060: Publish-Subscribe. This allows an entity to publish content to a publish-subscribe node, other entities that have previously subscribed to the node will receive the content.

In ActivityPub terms this is similar to following an actor and then receiving activities that the actor creates.

The publish-subscribe (pubsub in the following) mechanism in XMPP is more flexible as XMPP pubsub nodes are not bound to users (or actors in ActivityPub). Nodes can be created, configured and deleted dynamically by users for specific content. For example you can create a dedicated pubsub node for notices of lost cats in a specific area.

Personal Eventing Protocol

The flexibility of being able to create pubsub nodes makes discover-ability a bit more tricky. When you create a new XMPP account you may know the contact details of some people and want to follow content they post. How do you find the pubsub nodes that these people have created to post their personal content?

XEP-0163: Personal Eventing Protocol allows XMPP users to themselves become pubsub nodes (in fact many name-spaced nodes). This makes discovering personal content much easier. It makes following people as easy as in ActivityPub.

Microblogging

For microblogging (i.e. small textual contents) there is an additional XEP (XEP-0277: Microblogging over XMPP) that defines the format of the content and the named pubsub node where such content should be published.

GeoPub support XEP-0277 and can be used to create posts with geographic location. This makes GeoPub compatible with Movim and Libervia - two projects that use XMPP for social networking.

The format for microblogging posts defined in XEP-0277 is based on the widely used Atom Syndication Format (as defined by the IETF RFC 4278). This allows content created on an XMPP pubsub node to be exported and made available as an Atom feed accessible over simple HTTP.

XML

XMPP is an XML based protocol. Messages and content transferred over XMPP is formatted as XML. This allows formats such as Atom, XHTML, Docbook or RDF/XML to be directly transported over XMPP.

For openEngiadina we intend to use RDF/XML (an XML serialization of RDF) over XMPP. In fact, we intend to use the ActivityStreams vocabulary serialized as XML over XMPP. This allows, at least in theory, a very clean interoperability with the existing ActivityPub network.

The holy grail of ActivityPub servers is a generic server capable of handling any kind of data. With XMPP this is normal. XMPP servers transport XML but do not care about the content itself. Any existing XMPP server is adequate for openEngiadina.

Messaging and End-to-End Encryption

Another advantage of XMPP is that instant messaging is supported directly in the protocol.

A core tenet of openEngiadina is that content creation and curation is first and foremost a social activity. Quick and direct messaging is an important aspect of it and having this functionality built-in to the protocol is extremely valuable.

Furthermore, XMPP supports secure end-to-end encrypted communication (via XEP-0384: OMEMO Encryption).

Existing Software and Related Projects

One major appeal of XMPP is the availability of high-quality implementations (servers, clients and libraries).

On the server side there are ejabberd and Prosody. Both are well-tested and robust pieces of software that work and can be relied on.

XMPP clients exist for many platforms (see this list). There has been a renewed drive to develop and polish clients in order to make them viable alternatives to commercial instant messaging services (e.g. Dino, Snikket). Other clients are already extremely usable and mature (e.g. Conversations).

Why not Matrix?

Matrix is another federated protocol for instant messaging that also supports more complex applications.

Matrix does not seem like a good match for openEngiadina as the protocol is still in heavy development, there are practically no alternative server implementations. Furthermore, the protocol seems to do too much. It seems to be more like a distributed JSON database than a messaging protocol. This comes with a performance penalty and an inability to run Matrix servers on low-powered machines which is not acceptable for openEngiadina.

Other Changes

Previous versions of GeoPub were implemented in ClojureScript. GeoPub is now implemented in OCaml using the js_of_ocaml compiler. Reasons for this change were licensing issues as well as difficulties in providing reproducible development environments. A suitable and reproducible development environment for GeoPub can now be provisioned with Guix.

Hosting of code has moved from Gitlab to Codeberg. Reasons include that Gitlab stopped working properly with my browser and that codeberg seems to be a nice project.

Next Steps

Moving to XMPP is a bit of a step back as we need to re-implement all the research done towards the data model. This is what we intend to do next. In particular we intend to use content-addressed ActivityStreams over XMPP.

The fate of CPub - the generic ActivityPub server - is still undecided. We might re-purpose it for an XMPP to ActivityPub bridge or continue development as is.

Repression in Belarus

My fellow openEngiadina developer rustra is still being detained in Belarus on charges of organizing protests last year. He has reported being tortured.

This is a strong reminder of the ongoing repression in Belarus.

Please consider supporting activists and victims of political repression by donating to the Anarchist Black Cross Belarus or other organizations such as Amnesty International.

Acknowledgments

Thank you for making it so far and thank you for your interest!

The openEngiadina projects is supported by the NLnet Foundation trough the NGI0 Discovery Fund.

Rösti

2021-02-04T00:00:00Z

Sky

2020-09-09T00:00:00Z

GeoPub: ActivityPub for content curation

2020-04-06T00:00:00Z

As previously mentioned openEngiadina is developing a platform for creating, managing and using crowd-sourced data in meaningful ways.

It is my pleasure to announce an initial demonstrator of GeoPub, an application for curating crowd-sourced content.

For the impatient: Link to the demo.

GeoPub is still very rough edged and limited in functionality but I hope good enough to demonstrate two ideas:

How the ActivityPub protocol can be used to create, share and discuss any kind of structured content.
How a content-management system for crowd-sourced data might work.

This is an extended demo of the initial GeoPub version, discussion on some known issues, things that we have planned, a peek under the hood as well as an outlook on next steps.

For more background on the Semantic Web and Linked Data see a previous post.

GeoPub

Demo time! GeoPub is a web application and we have an instance hosted here. You can also get the sources here and compile it yourself.

On startup GeoPub will attempt to load some initial data. This might take a few seconds.

Once loaded, you will see a screen showing recent activity:

Every line corresponds to an activity performed by an actor (a person, organization or similar):

We see four pieces of information:

The actor who performed the activity (openengiadina).
The type of activity performed (Create).
The object the activity was performed on (Note).
When the activity was performed.

The types of activities are defined by the ActivityStreams Vocabulary.

Note that the actor, the activity type and the object are links that you can follow. For example you can follow the Note link.

This will take you to the "browse" view:

In the center pane you see the content of the Note ("Hello World!") and some additional information such as the identifier and type of the note.

In the right-side view related activities are displayed (for the Note we are viewing there is only the initial Create activity).

On the left there is a menu for browsing different types of content.

Activities as content

The activity itself is just "content" and has it's own identifier and can be viewed like the note by following the Create link:

We see that the created note was made public by addressing it to the special public collection (https://www.w3.org/ns/activitystreams#Public).

Events

So far there is not much that sets apart GeoPub from any ActivityPub client such as the Mastodon or Pleroma frontends (except that GeoPub does not look as nice and seems overly complicated). What makes GeoPub different is that it displays content regardless of its type.

For example the demo user alice created an event:

When following the link My super cool event we see that the type of the object alice created is an "Event":

In the "Related Activities" pane you see that Alice created the event, announced it and then Bob created a note that is somehow related to the event. The user interface for displaying the related activities is of course very rudimentary. For example you would want to see the content of Bob's note immediately when viewing the event.

Note that we are still in the realms of what is currently done with ActivityPub. Gancio and Mobilizon are applications that are specialized for creating, sharing and interacting with events over ActivityPub.

GeoPub on the other hand does not have any special knowledge about events. It does not treat the event type as a special type. It is not intended for creating content of a specific type. GeoPub is intended for browsing and curating a wide range of different content types. An event, a description of a hiking trail or a toot are equally interesting.

Let's see some content types for which there are no ActivityPub applications yet.

Ice cream shop

The user bob has created something with the name "Mauri Gelateria":

We follow the link and see the created content:

The type is IceCreamShop. We can even follow the IceCreamShop link and get more information on the type:

The type is defined by the schema.org project, a collection of types for defining structured data. There are many more concepts and properties that describe the concepts that are defined and can be used to describe things such as our Gelateria.

Given the right interface anybody can create structured content on their business, their organization or almost anything, publish it and allow social interactions via ActivityPub on the created content.

For example I can like the created ice cream shop:

This is the key idea we are trying to develop with openEngiadina: social interaction on arbitrary structured content.

The Fediverse and beyond

GeoPub is capable of getting data from many different sources.

For example it can get data from the Fediverse and display it:

The content is fetched directly from the Framasoft ActivityPub outbox. We also fetch the actor profile:

This data is loaded on initialization as sample data.

Note that there is an issue with CORS that might result in you not being able to get this data. See below under issues on how to get around it.

Embedded Content

Many websites publish embedded structured content in their HTML (using RDFa). GeoPub is capable of getting this data.

For example, this site (inqlab.net) has embedded meta data that can be fetched by entering the URL in the "Enter URL" form:

The data will be loaded and displayed:

Another nice example is radar.squat.net, an online portal of events and groups. Structured content is embedded in the HTML and can be read by GeoPub:

Many websites publish such structured content and GeoPub can fetch it and use it.

Curating crowd-sourced data

As seen above the Fediverse and the whole Internet serves as a source for content that can be browsed with GeoPub. The amount of information is almost unlimited, whereas the quality of data is not always up to standards.

It seems necessary for individuals and organizations to be able to create curated selection of content and share these selections.

On the Fediverse "Announcing" or "Boosting" is one way of curating content ("retweet" on the birdsite) - content that has been previously created is made visible to your followers.

A more elaborate way of doing curation is by creating collections. For example, adding existing content to a collection called "Events to publish on website". The interaction pattern is almost identical to announcing or boosting content, except that you need to choose to which collection the content should be added.

The content of this collection "Events to publish on website" can be made public and can be used by a static-site generator or a Wordpress plugin to render on a website.

We are working on implementing the ability to create collections of content in openEngiadina by implementing a Linked Data Platform - a bit like WebDAV for structured content. This is also the base specification of Solid.

For now we have implemented a simpler version of this: Liking - or in other words - adding things to a collection of liked content.

If authenticated you can like your favorite ice cream shop from GeoPub:

Under the hood

A quick peek under the hood of GeoPub.

ClojureScript

GeoPub is implemented in ClojureScript. We extensively use language specific functionalities and libraries in GeoPub (e.g. core.logic). it seems to be very well suited for "data-driven" applications.

Most importantly, ClojureScript is fun. Have a look at the code.

Parsers

A key functionality of GeoPub is the ability to get structured data from various sources in different formats.

This is done by using the RDF Parse JavaScript library. Which can parse data in Turtle, JSON-LD and RDFa (among others).

core.logic

In order to be able to handle all the data from various sources GeoPub implements a query engine using miniKanren, a very simple and lightweight embedded language for logic programming. We use the core.logic implementation of miniKanren in Clojure.

For example this allows us to very nicely query for all related activities to something:

(run* [id]
  (rdf-logic/graph-typeo graph id (as "Activity"))
  (fresh [p]
    (rdf-logic/graph-tripleo graph id p something)))

We query for the ids of all activities that have something as object for any property p.

The graph-typeo relation also handles type inference. We do not have to specify all the types of activities but can use the fact that specific activities (such as as:Create) are defined as sub-types of the as:Activity type.

We intend to implement more of such nice things (following the lines of Simple and Efficient Minimal RDFS) and also make the query engine directly usable from the interface.

Issues and what's planned

GeoPub is still far from being usable. Some of the issues we are aware of and some things we are planning to implement:

CORS

For security reasons browsers restrict HTTP requests initiated by scripts to sites other than the origin of the script (cross-origin requests).

This makes a lot of sense for the usual untrusted Javascript that gets loaded from random sources. However it limits applications that get data from many different sources, such as GeoPub.

Sites can opt-in to allow requests from cross-origin via a mechanism called Cross-Origin Resource Sharing (CORS). This needs to enabled manually on server-side. Practically it is impossible to get all server administrators to enable CORS. Practically it is impossible to implement a client side Linked Data web application.

We are thinking about ways to get around this limitation. If you have ideas, we would love to hear about them. Please get in contact.

If you would like to try the complete "Linked Data" experience now, I recommend using the CORS Everywhere plugin for Firefox.

There are other related issues that make consuming Linked Data from web clients challenging, such as mixed content.

Map

GeoPub has Geo in the name because it was initially conceived to handle geospatial data (such as points of interest, hiking trails, organizaitons with physical locations).

We intend to implement a map showing content that has location data attached.

Along the same lines we intend to implement a calendar view for data with dates (such as events).

Multilingual

RDF explicitly allows tagging the language of content. An note can have content in four different languages:

@prefix as: <https://www.w3.org/ns/activitystreams#> .

<https://openengiadina.net/objects/sample-note>
    a as:Note ;
    as:content "Good day!"@en ;
    as:content "Guten Tag!"@de ;
    as:content "Grüezi"@gsw ;
    as:content "Bun di!"@roh .

We intend to use this feature in the data model to pick the most appropriate translation for content.

The example above was encoded in Turtle. Multilingual content can also be encoded in JSON-LD:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Note",
  "contentMap": {
    "en": "Good day!",
    "de": "Guten Tag!",
    "gsw": "Grüezi!",
    "roh": "Bun di!"
  }
}

Persistent storage

Currently GeoPub does not have any persistent storage. We intend to implement persistent storage using the IndexedDB API.

This is an important step towards making GeoPub local-first software.

What's next?

A quick research stint into how Linked Data and RDF can be used in even more decentralized ways.

Unfortunately some aspects of the existing Semantic Web stack require a lot of centralized state manipulation (e.g. Linked Data Platform or Web Access Control) which seem unsuitable for decentralized platforms and also massively increase the complexity of servers.

Our motivation for doing this research is to keep any server logic as simple as possible and allow a transition to a completely decentralized architecture, while being compatible and data-interoperable with existing technology and data.

We want to explore and research:

Ideas like Event Sourcing and CQRS
Capability-based security and systems implementing it (e.g. Tahoe-LAFS, OcapPub)
Convergent and Commutative Replicated Data Types and systems like Irmin
How to implement efficient data stores on key-value stores (see SRFI-168 and node-quadstore)
Projects working on Linked Data inspired data models (InfoCentral and IPLD)

Acknowledgments

This work was supported by the NLnet Foundation trough the NGI0 Discovery Fund. Hosting of the demo instance is provided to us by ungleich.

I am very grateful for feedback, comments and questions.

GeoPub and openEngiadina is a collaborative effort. Join us in our Matrix channel.

Allegra openEngiadina!

2020-03-21T00:00:00Z

For the last couple of months I have been working on a project called openEngiadina. I am very happy to announce that openEngiadina is now being supported by the NLnet Foundation.

In this post I would like outline the background, the general ideas and the next steps of the project.

(Allegra is Hello in Romansch.)

Background

The openEngiadina project was started in 2019 in order to allow locals in the alpine valley of Engadin to make their cultural and natural heritage more accessible to visitors.

A system for creating and managing data such as points of interst, hiking trails and their real-time status, restaurant and hotel information as well as cultural events was needed.

We made two key realizations:

The cultural and natural heritage is expressed in very many different kinds of data points that are related in sometimes subtle ways.
The vast amount of data that needs to be handled, makes it practically impossible for a central authority to efficiently create and manage the data. Data needs to be crowed-sourced and crowd-managed.

What we need is a mashup between a knowledge repository and a social network. We call this a Semantic Social Network.

Semantic Social Network

A knowledge repository is a system that stores structured content and makes it available via semantic queries. For example one could ask a knowledge repository for a list of inventors that were killed by their own invention or all the public transport stops in Switzerland above 3000m. The key technology used to achieve this is Linked Data, which allows a combination of various kinds of data and makes them queryable.

There are many knowledge repositories and many more interesting data sets published as Linked Data. However, they mostly represent formally codified knowledge that was created by experts using specialized tools.

Without any formal codification of knowledge, we are extremely well capable of sharing, requesting and receiving knowledge via natural language. However, the amount of knowledge we can process via natural language and the number of sources we can consider is limited. Faced with an onslaught of data from modern communications systems, we are dependent on some sort of structure and codification of knowledge.

Existing social networks allow the codification of certain things as structured data. For example, you don't have to write a message describing the concert you are organizing. You can create an event that represents the concert. Important information about the event will be available in a structured way, allowing discoverability. Very much like information in a knowledge repository.

We realize that there is much power in the ability to structure knowledge and make it widely accessible and discoverable. At the same time we acknowledge the fact that structured knowledge can only emerge from social interaction via natural language (i.e. unstructured knowledge). openEngiadina wants to bridge this gap. It should be much easier to create arbitrary structured data in social networks, comment them, extend them and finally publish them. We want the status of a hiking trail to be as easy to update, share and discuss as a concert or an image of a cat.

Open Local Knowledge

There are thousands of little pieces of information and data that describe the social, cultural and natural environment of an area. This might include:

points of interest on a map (e.g. a mineral spring)
social and cultural activities (e.g. a concert)
descriptions for outdoor activities (e.g. hiking routes or snow reports)
local organizations and businesses (e.g. a book shop, a bakery or a hotel)
classifieds (e.g. somebody needs to borrow a drill)
status of infrastructure (e.g. snow cover on roads)

We call this local knowledge.

We believe that local knowledge should be freely available for everyone to use and republish as they wish, local knowledge needs to be open knowledge.

Furthermore openEngiadina emphasizes the importance for communities to create and manage their own data and be capable of operating the necessary infrastructure independently. We hope to help individuals and communities achieve digital sovereignty.

Beyond the valley

It is my great pleasure to announce that openEngiadina is receiving financial support from the NLnet Foundation trough the NGI0 Discovery Fund.

This allows us to do more in-depth research and generalize the ideas to communities beyond the valley.

Project overview

In the scope of the NLnet grant we are working on a couple of fronts towards a platform for open local knowledge. A detailed project plan is in the openEngiadina repository.

Here a quick overview:

Backend: We are developing a generic ActivityPub server called CPub. The idea is to achieve generality by embracing the right data model and doing as little as possible.
Clients: We strive towards an ecosystem where clients are specialized views of the data. Every client (or app) has a specialized function and view of data, that is stored in an interoperable way in a common place. Our flagship client is GeoPub which is an interface for content management for crowd-sourced data.

Data model and storage: The underlying data model for the platform is Linked Data, data is modeled as a graph. We are researching ways of making the data model more decentralized and useable on various platforms.
OpenStreetMap: A huge repository of local knowledge exists in OpenStreetMap. Unfortunately the data model is not perfectly suited for usage in Linked Data projects. Previous efforts have done much work towards making the OpenStreetMap data available as Linked Data (LinkedGeoData.org and OSM Semantic Network). Unfortunately these efforts have stalled and are currently not useable. We intend to revive these efforts and provide tooling for projecting OpenStreetMap data to Linked Data. This will allow local knowledge to be very closely linked to the existing OpenStreetMap data.
Search and Discovery: How can structured data be made searchable and discoverable in federated networks?

What's next

We have recently release an initial version of the backend and are now working on an initial release of GeoPub (a client). Together they will form an initial demonstrator that we hope to present very soon.

Join us in our Matrix room to stay updated: #openengiadina:matrix.org.

Acknowledgments

openEngiadina is being supported by miaEngiadina and the NLnet Foundation trough the NGI0 Discovery Fund.

We are also very grateful for hosting provided to us by ungleich.

Use Tor

2020-03-20T00:00:00Z

This site is now accessible as a Tor onion service:

inqlabtke3bpw47rbs7bkmtrz5l5jxuae4eltqwyglzzrpfubdr4kpad.onion

Use Tor!

A Primer on the Semantic Web and Linked Data

2019-11-19T00:00:00Z

The Semantic Web is a vision to make data on the Web interoperable and understandable to both humans and machines.

Unfortunately, the very idea of the Semantic Web is not easily understandable. RDF, XML, Linked Data, OWL, SPARQL, FOAF and a whole bunch of three-letter abbreviations form a cloud of terms and concepts that make it hard to get to the core ideas of the Semantic Web.

This is a short introduction to the Semantic Web with the hope of convincing you that its core ideas are surprisingly simple.

We approach the topic from the perspective of a data modeler who has been given the task of creating an information system for touristic data.

The initial motivational section requires basic knowledge of relational databases. If you want to skip ahead, you can start reading at the second section.

Touristic Data

A touristic information system should be able to handle data such as:

Hotels, hostels, guesthouses
Restaurants
Cultural events
Points of interest
Outdoor activities
Real time data such as weather or road status

A well-proven way of handling such data is with a relational database. We can define tables for each entity type (e.g. Restaurant, Hotel, Hiking Trail).

We realize that there are links between the entities in the data that we care about. For example:

A restaurant may be the venue for a cultural event
A point of interest may lie on a hiking trail
Accessibility to a hotel may depend on the status of a road (e.g. closed because of snow)

These links can be created in a relational database by explicitly defining relationships with foreign keys and possibly intermediate entities such as venues.

The data model quickly becomes very complicated. Furthermore, if in the future we need to add another data type (e.g. sport events), we would have to introduce a new table and a lot of new foreign keys all over our data model to be able to represent new relationships we might care about.

Is there another way of representing and processing such data?

Let's try using a graph.

A simpler data model: A graph

Let us try and model the data as a graph. We use nodes to describe concrete entities and abstract concepts (such as restaurant) and connect them with labeled directed edges.

We can say that "Pizzeria Dada" is a restaurant as follows:

If the Pizzeria Dada lies on a hiking trail we can extend the graph:

And if Johnny Cash happens to drop by in town for a concert, we can extend the graph further:

Expressing the data as a graph allows us to make interesting queries. For example, we could be interested in finding "all the concerts that are held along the hiking trail to Piz Blups". The answer to this query can be computed by traversing the graph and detecting certain shapes.

Triples

The basic unit of this data representation are two nodes that are connected with a labeled edge. This basic unit is called a triple. The node from where the edge goes out is called the subject, the edge is labeled with a predicate and the node receiving the edge is the object.

Our data model is a set of triples.

Note that subjects can have multiple outgoing edges:

and subjects can be the object of another subject:

Naming

Consider the situation where a node "Johnny Cash Live" was added to our graph:

Unfortunately, both "Johnny Cash Live" and "Johnny Cash Concert" refer to the same concert. The naming of the nodes is ambiguous. We need a naming convention.

For instance we could use Uniform Resource Identifiers (URIs) to name things:

Think of URIs as an address for a resource, as an Uniform Resource Locator (URL). URIs are a generalization of URLs, but we won't care about that distinction now.

By naming the node with an URI we've lost the human readable name. Let's add it with another triple:

We also use URIs to name abstract concepts and properties:

The node "Johnny Cash Live" remains as it is. It does not refer to anything, but is a value that describes something. We call such a node a literal.

We used names starting with http://schema.org and http://www.w3.org/1999/02/22-rdf-syntax-ns. These are names that have been previously agreed upon by a community. As we will see later, there are advantages in using commonly used names.

Linked Data

The basic unit of our data model are triples consisting of a subject, predicate and object. We name things and properties with URIs.

Recall that URIs are addresses for resources. What if at the address we used as a name for our nodes there is another graph that extends our graph?

For example we can have a graph that has a node http://somewhere-else.org/something:

If at the address http://somewhere-else.org/something we can retrieve data that is also in the graph fom that we have seen, for example:

Then we could combine the graphs:

Therefore, by using addresses (URIs) as names for nodes we are able to extend our graph with remote data. We can link our data with other data. This is called Linked Data.

Resource Description Framework

Let us recap our data model:

We model our data as graphs consisting of triples (subject, predicate, object)
We use URIs to name things
We can extend our graph by fetching more data from the URIs of things

The idea behind Linked Data is that we can link our data to other remote data sources and use the same tools and processes on the combined data.

The model that we introduced is called Resource Description Framework (RDF). RDF specifies the exact model and form of triples. It is a concrete specification of Linked Data.

RDF does not specify any particular way of serialization (a machine-readable format for writing down the graph). There is an XML serialization for RDF, a more human-readable format called Turtle and a JSON serialization (called JSON-LD). Unfortunately, these serializations are very complicated and hard to implement (especially the XML and JSON ones), which has caused a lot of confusion about RDF in general.

Let us not worry about serialization for the moment and admire RDF as a simple and powerful data model.

Semantic Web

Using RDF allows us to link remote data sources together and use them in a unified way. This enables interoperability.

But what makes data understandable?

Unambiguous identifiers for things and predicates makes the data understandable.

In RDF we need to use URIs for naming things or naming predicates that describe things. By using the same names to talk about the same thing in different contexts we make things understandable across contexts.

This seems straightforward when naming things. For example, we could use the URI http://example.org/Alice to uniquely describe the person Alice, and Alice would be described in two different data sets with the same URI. In this way, we understand that both data sets describe Alice and the combination is a more complete description of Alice.

The same also holds for names of predicates. For example, the predicate http://schema.org/address can be used to describe the physical address of an item. If we want to send a letter to some subject we would need to check if the subject is in a triple with the predicate http://schema.org/address and send the letter to the object of that triple. The subject could be a person, an institution, or anything that could have a physical address. We don't need to care. We understand that if the subject has the address predicate, we probably can send a letter to it.

When combining different data sets it is necessary that the same names are used to describe the same things. If one data set uses the predicate http://schema.org/address is used and another uses http://noschema.com/postalAddress, then we won't be able to understand that they are both talking about the same thing.

It is very important to agree upon a common vocabulary for naming things. There are several projects that aim to provide vocabularies to describe many things (see links at the bottom of this page).

Let us recap:

The Semantic Web is a vision to make data on the Web interoperable and understandable.
Linked Data is an idea on how multiple remote data sources can be made interoperable.
RDF is a concrete implementation of Linked Data.
Meaning and understanding comes from using same names for same things.

That sounds great! Does RDF/Linked Data solve all my problems?

Probably not. Even if the data model is simple and powerful there are some drawbacks:

The tools and technology used to handle RDF/Linked Data are not as widely used - and maybe not as usable - as other stacks (e.g. relational database).
The data model is conceptually different from the more prevalent relational model and requires some mental effort to get used to.
Widely used serialization formats of RDF are extremely complicated and difficult to implement (RDF/XML, JSON-LD).
Agreeing upon a vocabulary to describe data is hard and requires a lot of social collaboration.

Nevertheless, Linked Data is extremely well suited for distributed systems where data interoperability is a high priority.

In a future post titled The Semantic Social Network I hope to illustrate how the Semantic Web and Linked Data can be used to create structured content in federated and decentralized networks in a crowd-sourced manner.

Lord of the Flies

2019-10-22T00:00:00Z

A sky of white and blue

mountains and flies

bzzzzzzzzzz

Der Hase und der Igel

2019-09-14T00:00:00Z

Der Hase ist davon überzeugt der Schnellste im ganzen Davos zu sein. Er fordert den Igel zu einem Rennen auf den Flüela hoch.

Am vereinbarten Samstag treffen sich die zwei im Dorf. Die Starpistole wird abgefeuert. Der Hase düst und eilt, Kurve um Kurve geschickt und flink. Am Tschuggen vorbei und boom. Ein rassender Porsche hat ihn erfasst.

Zwei Wochen später erreicht der Igel als Gewinner die Passhöhe. Zeit für Pause gibt es aber nicht, bald kommt der Schnee.

Large Underground Temple

2016-03-14T00:00:00Z

Hong Kong to Kunming

2015-03-02T00:00:00Z

Karawane

1916-02-05T00:00:00Z

jolifanto bambla o falli bambla

großiga m'pfa habla horem

egiga goramen

higo bloiko russula huju

bosso fataka

ü üü ü

schampa wulla wussa olobo

hej tatta gorem

eschige zunbada

wulubu ssubudu uluwu ssubudu

tumba ba-umf

kusa gauma

ba - umf