Mirror of the Rel4tion website/wiki source, view at <http://rel4tion.org>

Clone

HTTPS: git clone https://vervis.peers.community/repos/yEzqv

SSH: git clone USERNAME@vervis.peers.community:yEzqv

Branches

• master

Tags

ontology-cooperation.mdwn

Purpose

Design an architecture and a work process for collaborative ontology authoring.

Content

Two aspects of the network must be considered:

1. Cooperative definition of ontologies
2. Sharing of data across the web

This page talk about the first aspect.

How can ontologies be shared? This question has already been discussed briefly in the plan, but now a thorough solution and design is needed. What if many people need to modelthe same concept? What if they model them, doing work already done by someone else in parallel, without knowing about each other? Many solutions were tried over the years, and all of them have weaknesses. The solutions proposed here will probably have weaknesses too, but hopefully they will make a step forward.

Before suggesting ideas, two lists will be made:

1. List of downsides of existing solutions, and things missing from them
2. List of requirements derived from the first list and from the design concepts

Let us begin. Here is the first list, containing downsides, weaknesses and missing features:

• The development model of ontologies is centralized, a single dedicated team develops new ontologies for global use
• If someone wants to make an update or an edit, they must contact the team and pass a long evaluation process
• There is no standard way to adapt existing databases to non-compatible changes in the ontologies they use
• There is no standard versioning scheme for ontologies, e.g. the library versions used by libtool
• Usage of personally authored ontologies and equivalence properties are not common

And here is the second list, containing requirements:

• When looking for an ontology to describe a specific domain, it should be easy to find one if it exists
• The licenses of ontologies should be copyleft, e.g. CC-BY-SA can be chosen as a standard license
• When deciding to write an ontology for a domain, a global declaration should be made, so new people can join the effort and think together instead of starting the same thing in parallel
• Making an addition can be done locally without affecting other users and data compatibility, like a git branch
• When making a non-compatible change, e.g. changing a property’s range, it is done in a coordinated manner
• Adaptation of databases to non-compatible changes is automated as much as possible and performed when installing
• Ontologies will have a standard version numbering scheme to indicate compatibility
• Ontology merging and equivalence properties must be common and have easy processes

This should be enough to start.

TODO develop a system which implements these ideas