FEP-cb76: Content Addressed Vocabulary

Standards Fediverse Enhancement Proposals
,
8

An alternative method to explore – using urn:publicid with a public identifier based on the FEP that defines the extension term:

{
  "@context": {
    "fep": "urn:publicid:fep:",
    "canReply": "fep:5624:canReply"
  }
}

The above would basically be equivalent to saying:

  • The term fep maps to the prefix urn:publicid:fep:
  • The term canReply maps to the compact IRI fep:5624:canReply which expands to the full IRI urn:publicid:fep:5624:canReply

In essence, we would be using the public identifier fep:5624:canReply and turning it into a URN via the URN scheme urn:publicid.

  • Pro: no need to hash a definition text. We instead refer directly to the FEP that defines all semantics for the term definition.
  • Con: if an FEP is superceded, would any terms defined by that FEP become deprecated? (I guess this depends on how the FEP process handles follow-up FEPs.)

Maybe that con isn’t really a con? Maybe it would actually be beneficial to have a way to refer to different versions of a term that require different implementations.

In some ways, this mirrors the XEP ecosystem for namespaces and node identifiers. For example, OMEMO as defined in XEP-0384 currently uses the namespace urn:xmpp:omemo:2 and the node identifer urn:xmpp:omemo:2:devices.

But I guess that raises another con…

  • Con: What if the FEP process ends up in the future requesting an official URN namespace from the IETF? That would cause all existing URNs in existing documents to be orphaned. And there’s no way to define urn:fep as equivalent to urn:publicid:fep, because JSON-LD forbids mapping an IRI to anything other than a definition. (See Examples 42-44 and the associated warnings: JSON-LD 1.1)

Perhaps that is “too formal”, but it is something that might be proposed or done at some point. So adopting urn:publicid in essence implies a recommendation against getting an “official” urn:fep namespace in the future.