forgefed/vocabulary

Project Hosting Federation Vocabulary

Intro

This is a draft of a linked data / semantic web vocabulary for expressing information about version control repos and related technology such as issues and merge requests. It's meant to be used for decentralization of project hosting by making repo hosting platforms federate using ActivityPub.

The vocabulary here is going to be an extension to the ActivityStreams 2 vocabulary (to which ActivityPub is an existing core extension).

I suggest we start by keeping 2 lists: A list of classes (kinds of things, e.g. "repo" and "merge request" and "issue" etc.) and a list of properties (e.g. "name", "description", "main-branch", "creation-time").

For a class, specify:

• Name
• Description
• Superclasses (e.g. Person is a subclass of LivingBeing)

For a property:

• Name
• Description
• Superproperties (e.g. 'loves' is a subproperty of 'knows')
• Domain (e.g. in "A loves B", A probably has to be a person, or at least some living being)
• Range (e.g. in "A lives at B", B has to be a Location/Place)

The file VOCABULARY.md contains these 2 lists. Other files such as ISSUE.md have plans and ideas and info, based on which the vocabulary is gradually written.

The intention is to reuse properties and classes in the RDFiverse and ActivityPub! Some things in VOCABULARY.md may be removed in favor of existing entities defined in such places. As a result, though, we need to provide guidelines for the stuff that should be included in JSON-LD data sent between servers! For example, if we reuse dc:author from the Dublin Core ontology, eventually ISSUE.md should have an example for a JSON-LD issue object, to show the use of dc:author there.

We may need a base URI for the ActivityPub extension. I suggest we add the following mapping to the JSON-LD context:

"forge": "https://forgefed.peers.community/ns#"

And we can put in this namespace everything that doesn't come from other places. Later that mapping could be changed into a remote context URL, but, let's leave that cosmetic detail for later (also I must say, I don't like this pretentious cramming of everything into 1 remote context like AP does; I like the general RDF way where you just freely add namespace prefixes and use whatever you like from the RDFiverse).