FEP-2e40: The FEP Vocabulary Extension Process

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. if we take inspiration from XMPP and the XEP specifications, the proper way forward would be to have a general fep namespace similar to urn:xmpp. this is why in FEP-cb76 (comment) i discussed using urn:publicid:fep as the base (although the current state of that FEP uses urn:sha256 which isn’t really backed by any RFC, though it is used in bittorrent magnet links nonetheless). in that regard, the proposal to use https://w3id.org/fep is possibly the next-least-bad thing – it is still a URL and therefore could possibly break, although the w3c permanent identifier cg promises they won’t. we could probably bikeshed about the exact URL to use, which i suspect would be driven mainly by what the intended purpose of the URL would be. if we grandfathered in terms from existing contexts, then the “fep” part could be a bit misleading, but this probably doesn’t matter.

honestly, the thing that makes the most sense to me would be to merge the two approaches – have https://w3id.org/fep be a URL that resolves to a JSON-LD context, but have the individual terms be defined by URNs. something like this would result in canReply mapping to urn:publicid:fep:5624:canReply

{
  "@id": "https://w3id.org/fep",
  "@context" : [
    {
      "fep": "urn:publicid:fep:",
      "canReply": "fep:5624:canReply"
    },
    "https://www.w3.org/ns/activitystreams"
  ]
}

the alternative would be to use URLs for the term definitions too. something like this would result in mapping canReply to https://w3id.org/fep/5624/canReply

{
  "@id": "https://w3id.org/fep",
  "@context" : [
    {
      "fep": "https://w3id.org/fep/",
      "canReply": "fep:5624:canReply"
    },
    "https://www.w3.org/ns/activitystreams"
  ]
}

personally i see no real use in having terms map to URLs except in the very niche case where you want the term/property to resolve to its own definition. URNs are superior in every other way because this problem space is fundamentally about naming things, not locating things. but it is, in the end, a preference. https://www.xfront.com/URLversusURN.pdf talks more about this.