Specification of Linked Open Actors (LOA)

Version: 0.0.4


Linked Open Actors (LOA) specifies an Information Exchange Datamodel for exchanging data about Actors and Events between platforms.

Some history about the name:
We started with the working title fairsync. At that time we still thought that synchronization between platforms is a good way to achieve interopability. We then realized that Resource Description Framework (RDF) is a suitable format to exchange data between platforms. And since we are talking about Open data, it was obvious that it is Linked Open data. At that time we were experimenting with the ISA2 standard and foaf:Agent seemed to be the base class of the data we wanted to exchange. The name Linked Open Agents (LOA) was born. After diving deeper into the ISA2 documents and getting initial feedback on our exchange format, we saw that it is much more interoparable to rely on the schema.org standard. And this is also compatible with ISA2. But now the base class was no longer foaf:Agent. In the meantime we had gained more experience with ActivityPub and saw more possibilities to see platforms as ActivityPub actors. And also the data acting of actors ( Application, Group, Organization, Person, Service.) So Agent became Actor and now we talk about Linked Open Actors (LOA). More about the history can be found here We outsourced the specification to a separate project in February 2021 so that we are able to enable a contributor process and to easily publish this specification as a website. At this time, the domain https://linkedopenactors.org was also reserved, pointing to this documentation. The project page will continue to be the fairsync project page.

Update Mai 2021: While discussing with WECHANGE about the interfaces and the adapter implementation, we found out, that the specification and the website has different release cycles. The content of the website will change more often than the content of the specification. and the versioning of the website content is independent of the versioning of the specification. And of course, the versioning of the specification is far more important. So we have decided to run the specification as an independent project with an independent release cycle. The domain https://linkedopenactors.org will continue to point to the website and the specification will be a new gitlab page.

Context and requirements



Actor is on the one hand derived from the term Actor in the Activity Pub Context and on the other hand our defition is:

An actor is a person or an organization that is active in a certain context. For example https://wandelbuendnis.org or https://www.w3.org/People/Berners-Lee


An actor who takes on one or more [Roles]. A LOA actor shall be an ActivityPub Service.
An LOA actor provides information about its services via an actor object.


An event is a temporary and planned event with a defined objective or purpose. For example makers4humanity-Lab, 2018




An entry (Publication) provided by a platform that represents an organization or event. This entry primarily contains metadata about the provided data, such as version, identifier, hashtags, …​ .
But also a reference to the provided data


An Algorithm is able to compare two things. A thing can be

  • a simple property like legalName,

  • but also a more complex object like location, Address, etc.


Data Provider

A platform providing data about Organisations and Events in a platform specific format. E.g. openfairdb (Datenbank von Karte von Morgen), WeChange.

Data Consumer

A platform that consumes Data of a Data Provider in a Data Provider specific format.

LOA Data Provider

A platform providing data about Organisations and Events in LOA format.

LOA Data Consumer

A platform that consumes Data of a LOA Data Provider in LOA format.


A platform providing a SPARQL Endpoint for querying Organisations and Events in LOA format.

Tripe Store Server Provider

A platform that provides a Triple Store Serve like RDF4J. This can be a LOA Data Provider, but also a third party Software as a Service (SaaS) Provider.

LOA Algorithm Provider

Provides one ore more algorithms for different purposes.
- MUST provide a list of its algorithms in Turtle format and should provide the list as html.
- MUST provide details about each provided algorithm in Turtle format.
- MUST provide a HowTo for each provided algorithm in HTML format.
- MUST provide as a web service for each provided algorithm that allows the execution of that algorithm. CAN provided also other services & libraries that makes the algorithm executable.

Comparator Provider

TODO describe

LOA Merger Provider

TODO describe

LOA Similarity Check Provider

TODO describe

Use Cases

Create LOA Data

HTTP Post to a LOA Data Provider that contains a Publication with a referenced Organisation/Event.

Read LOA Data by IRI

HTTP Get to a LOA Data Provider. Requested Url is the IRI of the Publication to Read.

Update LOA Data by IRI

HTTP Put to a LOA Data Provider. Requested Url is the IRI of the Publication to Read. Body contains a Publication with a referenced Organisation/Event.

Delete LOA Data by IRI

HTTP Delete to a LOA Data Provider. Requested Url is the IRI of the Publication to Delete. Referenced Organisation/Event is also deleted.

Query LOA Data by SPARQL

HTTP Get to a Tripe Store Server Provider containing the SPARQL query.

Sync LOA Data with a 3rd party adapter

If there is a plattform, that is not (or not yet) able to provide LOA UseCases, someone else can provide loa-adapters that use data from the plattform in a direct or indirect way.

Information exchange data model

loa information exchange data model


Datatype: CreativeWork

Property Description


The version of the Publication, corresponds to the version of the Data Provider


A reference to the Organisation or event that is publicated by this Publication


The copyrightNotice of the Publication, corresponds to a copyrightNotice of the Data Provider


"Work State" of the Publication, corresponds to a state of the Data Provider


If available the date of creation of the entry at the Data Provider, if not the first LOA publication date.


The date when the data was updated the last time


The license of the Publication, corresponds to the version of the Data Provider


The hashtags of the Publication, corresponds to the hastags of the Data Provider


The identifier of the Publication, corresponds to the identifier of the Data Provider


The url where the original entry of the Data Provider is available. If the Data Provider is a LOA Data Provider the data must be provided with Content Negotiation. Media-Type application/json+jd is mandatory, turtle is optional.


A Description of the Publication


Datatype: Organization

Property Description


The name of the organisation.


The legalname of the organisation. Must only be there, if it is a legal organisation.


Link to the Homepage of the organisation.


Datatype: Place

Property Description




Datatype: ContactPoint

Property Description


The name of this contact Point. e.g. "Work", "Home"




Datatype: [PostalAddress](https://schema.org/PostalAddress)

Property Description


e.g. 82333


e.g. Munich


e.g. Bavaria


e.g. Germany


e.g. Wasserburger Landstrasse 263


Datatype: Event

Property Description


The name of the event. e.g. MakersLab, Mitwelt Festival 2022


A description of the event


The start date and time of the item ( in ISO 8601 date format ).


The end date and time of the item ( in ISO 8601 date format ).


The organisation, that organazies this Event.


The location (schema:Place) of, for example, where an event is happening, where an organization is located, or where an action takes place


Link to an image of this event.

ISA2 Mapping

Core Vocabularies internal identifier Mapping relation Target identifier Comment


Has close match

Organization - legalName


Has close match



Has narrow match


zivilgesellschaftiche OrganisationNGO;
öffentl. EinrichtungGovernmentOrganization;


Has close match

PostalAddress - postalCode


Has close match

PostalAddress - addressCountry


Has close match

PostalAddress - addressRegion


Has close match

PostalAddress - addressLocality


Has close match

PostalAddress - streetAddress


Has close match

Place - longitude


Has close match

Place - latitude


Has close match

Organization - location


Has close match

Organization - location - address

Merging LOA Organisations


LOA is based on the Resource Description Framework (RDF) and thus on triples. A triple has a subject (Gegenstand), a property (Eigenschaft), and a value (Wert).


In object-oriented programming, a subject is known as an object or entity.

A value of a triple can be
1. an Internationalized Resource Identifier (IRI), which means a reference to another subject.
2. a literal (text, number, date, …​)


ex:1236228 a schema:Organisation;
  schema:name "Backery Müller";
  schema:sameAs ex:299376;

The triples pictured above are:
1. The subject ex:1236228 is an Organisation
2. The subject ex:1236228 has a name "Backery Müller"
3. The subject ex:1236228 is the same as ex:299376

The 3. triple has a reference as a value!


To compare an RDF subject, its properties must be compared. For this purpose, LOA uses algorithms.

A LOA publication consists of several subjects, see Information exchange data model. To determine if a organisation is the same as another organisation, many properties of different subjects have to be compared. The result of this comparison is a set of triples with a comparison result.

Now, "equality" is mathematically objective. A name "Manfred" is not equal to the name "Lutz". However, "Manfred" is more unequal in comparison to "Lutz" than to "Fred". Therefore, an algorithm may return 0 in the case of "Lutz" and 50 in the case of "Fred". To compare properties different algorithms can be used. Depending on the property to be compared, a corresponding algorithm may be more or less suitable.

And now equality becomes "subjective"! Since a human decides which algorithm is to be used for which property and how the result of the algorithm is to be judged. (Assumption: For the time being LOA does not use artificial intelligence (-;)

These decisions of which algorithms to use are summarized in a Comparator.

the equality of subjects

And now it becomes exciting, because there must still be an instance, which decides, what means equality and how to deal with it. That is still open and must be considered. In my (Fredy) head this task will be done by a SimilarityChecker and/or a Loa Merger. For the time being, the UseCases have to be analyzed.


An algorithm compares literals. The result is a number (integer). An algorithm must describe itself with the following attributes:

  • name - The nameof the algorithm.

  • description - A short description of what the algorithm calculates.

  • mainEntityOfPage - A link to a detailed description of the algorithm in HTLM (text/html).


@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix fabio: <http://purl.org/spar/fabio/> .
@prefix schema: <http://schema.org/> .
@prefix loaalgo: <http://localhost:8080/algorithm/> .

loaalgo:distanceCalculator a fabio:Algorithm;
  schema:name "distanceCalculator";
  schema:description "Calculating the distance between to geo locations.";
  schema:mainEntityOfPage loaalgo:howTodistanceCalculator .

There can be more complex algorithms if there is a need for comparing more than one property. This is for example the case if the distance betwee two geo locations has to be compared. And the geo location is provided by the properties longitude & latitude.

List of available algorithms

TODO define the list format!



A comparator specifies: - Which properties to compare.
- Which algorithm is used to compare a property.
- A Comparator does NOT determine: How to evaluate the result of the Algorithm.

A Comparator compares two LOA publications.

The ComparatorInput consists of two lists of triples: - List of subjectA triples
- List of subjectB triples
The lists can contain graphs, i.e. several referencing subjects.

The output of a Comparator consists of a list of ComparatorOutput : - subjectA
- subjectB
- usedAlgorithm
- List of ComparatorOutputProperty

ComparatorOutputProperty - property
- propertyValueA
- propertyValueB
- result


This is an activity of the fairsync project, funded by NLnet.


Fred Hauschel
Software Engineer

Roland Alton
Communication Engineer


Ask your questions and discuss with us on fairsync
Bigger topics are discussed here: here