DRAFT
LOA

Specification of Linked Open Actors (LOA)

Version: 0.0.4

Introduction

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

Terms

Actor

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

LOA-Actor

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.

Event

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

Organisation

TODO

Publication

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

Algorithm

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.

Roles

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.

LOA SPARQL Provider

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

Publication

Datatype: CreativeWork

Property Description

version

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

about

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

copyrightNotice

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

creativeWorkStatus

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

dateCreated

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

dateModified

The date when the data was updated the last time

license

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

keywords

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

identifier

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

url

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.

description

A Description of the Publication

Organisation

Datatype: Organization

Property Description

name

The name of the organisation.

legalName

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

url

Link to the Homepage of the organisation.

Place

Datatype: Place

Property Description

latitude

longitude

ContactPoint

Datatype: ContactPoint

Property Description

name

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

email

telephone

PostalAddress

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

Property Description

postalCode

e.g. 82333

addressLocality

e.g. Munich

addressRegion

e.g. Bavaria

addressCountry

e.g. Germany

streetAddress

e.g. Wasserburger Landstrasse 263

Event

Datatype: Event

Property Description

name

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

description

A description of the event

startDate

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

endDate

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

organizer

The organisation, that organazies this Event.

location

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

image

Link to an image of this event.

ISA2 Mapping

Core Vocabularies internal identifier Mapping relation Target identifier Comment

LegalEntityLegalName

Has close match

Organization - legalName

LegalEntityAddress

Has close match

PostalAddress

LegalEntityCompanyType

Has narrow match

Organization#subtypes

zivilgesellschaftiche OrganisationNGO;
öffentl. EinrichtungGovernmentOrganization;
Unternehmen(kommerziell)Cooperation;
sonstigesOrganisation

AddressPostCode

Has close match

PostalAddress - postalCode

AddressAdminUnitL1

Has close match

PostalAddress - addressCountry

AddressAdminUnitL2

Has close match

PostalAddress - addressRegion

AddressPostName

Has close match

PostalAddress - addressLocality

AddressAddressArea

Has close match

PostalAddress - streetAddress

GeometryCoordinates

Has close match

Place - longitude

GeometryCoordinates

Has close match

Place - latitude

LocationGeometry

Has close match

Organization - location

LocationAddress

Has close match

Organization - location - address

Merging LOA Organisations

Introduction

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).

triple

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, …​)

Sample:

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!

Comparison

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.

Algorithms

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).

Sample:

@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!

Comparator

!! DRAFT - DRAFT - DRAFT !!

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

About

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

Team

Fred Hauschel
Software Engineer
http://hauschel.de

Roland Alton
Communication Engineer
https://roland.alton.at

Contact

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