|zPlus 05ddb5d44c Use correct RDF URI.||1 year ago|
|COMMENT.md||1 year ago|
|ISSUE.md||1 year ago|
|PULL-REQUEST.md||1 year ago|
|README.md||1 year ago|
|REPOSITORY.md||1 year ago|
|VOCABULARY.md||1 year ago|
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:
For a property:
VOCABULARY.md contains these 2 lists. Other files such as
have plans and ideas and info, based on which the vocabulary is gradually
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,
ISSUE.md should have an example for a JSON-LD issue object, to
show the use of
We may need a base URI for the ActivityPub extension. I suggest we add the following mapping to the JSON-LD context:
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).