FEP-2e40: The FEP Vocabulary Extension Process

[aschrijver]

@trwnh

i don’t think “domain-specific namespaces” makes sense. there shouldn’t be an arbitrary division between a “video” server and a “microblog” server. an activitypub server is an activitypub server.

I think we may have a clash of semantics here? With “domain” I meant the conceptual space for which you define a formal ontology/vocabulary (i.e. domain driven design ddd:domain, not dns:domain ).

@trwnh

in FEP-cb76 (comment) i discussed using urn:publicid:fep as the base

You can only use IRI’s in Linked Data, and preferably (SHOULD) they are dereferencable. In JSON-LD 1.1 chapter 3 it says:

Furthermore, developers and machines are able to use this IRI (by using a web browser, for instance) to go to the term and get a definition of what the term means. This process is known as IRI dereferencing.

And further down in chapter 8 Data Model:

An IRI (Internationalized Resource Identifier) is a string that conforms to the syntax defined in [RFC3987]. IRIs used within a graph SHOULD return a Linked Data document describing the resource denoted by that IRI when being dereferenced.

Hence I am not sure whether using a URN in the @context as per Content Addressed Vocabulary is valid JSON-LD at the moment.

(OT: I stumbled in an interesting paper in the context of Verifiable Credentials when searching for this, and it led me to check W3C DID specs. And creation of this topic → Linked Data versus ActivityPub )

The Decentralized Identifiers (DID) is very extensible, and I found this document that formally tracks all known extensions: DID Specification Registries. Something like this is usable for our FEP Ontology Process. Quoting the entire Chapter 3:

3. The Registration Process

Software implementers might find that the existing Decentralized Identifier Core specification [DID-CORE] is not entirely capable of addressing their use case and might need to add a new parameters, properties, or values to this registry in order to achieve their use case in a globally interoperable fashion. In order to add a new parameter, property, or value to this registry, an implementer MUST submit a modification request for this registry, as a pull request on the repository where this registry is hosted, where the modification request adheres to the following policies:

1. Any addition to the DID Core Registries MUST specify a human readable description of the addition.
2. Any name or value of a property or parameter MUST be indicative of its function. Avoid generic terms such as “myProperty” or “foo”.
3. Any method name SHOULD avoid generic terms such as “mymethod” or “registry”.
4. If there are copyright, trademark, or any intellectual property rights concerns, the addition and use MUST be authorized in writing by the intellectual property rights holder under a F/RAND license. Examples include DID Methods that use trademarked brand names, property names that utilize the titles of copyrighted works, and patented technology that would cause the use of the extension to require licensing a patent.
5. Any addition MUST NOT create unreasonable legal, security, moral, or privacy issues that will result in direct harm to others. Examples of unacceptable additions include any containing racist language, technologies used to persecute minority populations, and unconsented pervasive tracking.
6. Any addition to the DID Core Registries MUST link, via at least a URL, preferably a content-integrity protected one, to the defining specification so that implementers can implement the property.
7. Any addition to the DID Core Registries that is a property or value, MUST specify a machine readable JSON-LD Context for the addition.
   • The JSON-LD Context MUST be included in full as part of the submission.
   • A namespace URI MUST be provided for the JSON-LD Context so that consumer implementations can consistently map a URI to the full context.
   • The URI provided MUST be persistent, and link all terms to their associated human readable descriptions.
   • The URI provided SHOULD resolve or link to the full context contents.
   • JSON-LD Contexts MUST be versioned and MUST NOT be date stamped.
   • JSON-LD Contexts SHOULD use scoped terms and MUST use the @protected feature to eliminate the possibility of term conflicts.
8. Properties in the DID Core Registries MUST NOT be removed, only deprecated.

The Editors of the DID Specification Registries MUST consider all of the policies above when reviewing additions to the registry and MUST reject registry entries if they violate any of the policies in this section. Entities registering additions can challenge rejections first with the W3C DID Working Group and then, if they are not satisfied with the outcome, with the W3C Staff. W3C Staff need not be consulted on changes to the DID Specification Registries, but do have the final authority on registry contents. This is to ensure that W3C can adequately respond to time sensitive legal, privacy, security, moral, or other pressing concerns without putting an undue operational burden on W3C Staff.

Entries that are identified to cause interoperability problems MAY be marked as such at the discretion of the maintainers of this registry, and if possible, after consultation with the entry maintainer.

Any submission to the registries that meet all the criteria listed above will be accepted for inclusion. These registries enumerate all known mechanisms that meet a minimum bar, without choosing between them.

Human readable

Note that both JSON-LD and DID specs emphasize human-readable (specifically developers/implementers) quality of the document, in addition to machine-readability. Seen in that light names such as fep:5624:canReply while refering to the FEP’s ID lose readability. You can only know what they are about by dereferencing the IRI.

Also note that in terms of how FEP’s relate to ontologies there is no 1-to-1 mapping at the moment. And maybe there shouldn’t be one either, so that FEP’s and ontologies (which define AP vocab extensions) are entirely separate. This corresponds to a division I mentioned many times on this forum before of (in decreasing order of formality) having separation into 3 process tracks:

1. Open standards → formal specifications (must use)
2. FEP’s → common, recommended protocol extensions (should use)
3. AP Vocabulary extensions → domain-specific ontologies (may use, depends on use cases)

Update: @helge’s FEP in this context is really the one that should be scoped to define 3) and is well underway to do so, looks like?

AP Vocabulary extensions

I see that we agree a best-practice is to avoid project/vendor-specific namespaces where possible, and in the interest of broad interoperability.

@helge

If I wanted to understand a current lemmy message, what would I naively do:

Another example. One thing Lemmy defines in its @context is a property lemmy:moderators. Yesterday we heard that Discourse gets federation support and takes Lemmy as their guide. Discourse also has Admins, and - with current practice - might end up having a further extension with discourse:admins. Will they keep lemmy:moderators for interoperability or be consistent to their own app and have discourse:moderators?

These privilege levels are part of some common domain / ontology / vocabulary that should be defined once, and can then be shared by many different types of applications where it makes sense to have them. What should be the best name for this vocab extension? I don’t know. It should be as descriptive as possible, not too broad and not too narrow in scope.

An example vocab extension is the Security Vocabulary that both ActivityPub and DID use. See JSON-LD at: security-vocab context.

(Funny @trwnh, we have another sec:domain here )