This is true for the FEP (as your context includes a SHA256 hash only), but I am at this point thinking of a different proposal, which is to use urn:publicid
coupled with an fep
namespace that has sub-namespaces for each FEP in particular (fep:5624
would contain terms for FEP-5624, such as fep:5624:canReply
). This is analogous to XMPP’s XEP namespacing, such as urn:xmpp:omemo
for XEP-0384: OMEMO Encryption.
This part is fine. I don’t have any issues with this; in fact, I think it is a good idea for bundling up all FEPs into a singular context for JSON-LD processors, similar to the schema dot org or the activitystreams contexts. I just think that the definitions shouldn’t necessarily be URLs. In other words, I think urn:publicid:fep:5624:canReply
expresses more clearly “this is the canReply
property as defined by FEP-5624” rather than https://w3id.org/fep#canReply
which instead expresses “this is the canReply
property as adopted by the FEP process”. The latter implies some sort of unity among the FEP process which isn’t really there. If we want it to be there, we need to change some things about the process, especially regarding how FEPs are superceded and how property names are defined/adopted:
- Can anyone supercede anyone else’s FEP?
- What if different projects adopt different FEPs, such as one project adopting the old term definition while another project adopts the replacement term definition? Do we discourage or disallow using certain names just because they have already been used by a past FEP?
- Following this line of thought: Is it our responsibility to maintain a consistent vocabulary or ontology? It would be kind of like if the IETF decided that all RFCs must be consistent with each other.
Over on the XMPP side, the XEP process has an “experimental” phase in which namespaces (and names) can change. Taking OMEMO as an example, if we want to fetch the device list for any account, this has over time been defined as urn:xmpp:omemo:0:devicelist
, urn:xmpp:omemo:1:devices
, and currently urn:xmpp:omemo:2:devices
– each namespace change represents an incompatible breaking change in the experimental spec. Sometimes the property names change.
Instead, the FEP process seems to have gone for a process that includes supercession by future FEPs rather than allowing “experimental” FEPs. The XEP has an authoritative namespace (urn:xmpp
) registered to the XMPP Standards Foundation. The FEP process has no such thing. The proposal to use https://w3id.org/fep
in effect establishes such a namespace for the FEP process, but it does not have any consideration for sub-namespaces. Sub-namespaces for XEPs are managed by authority of the XSF – you can register a sub-namespace like urn:xmpp:omemo
as part of your XEP. Sub-namespaces for FEPs are not supported under this current proposal. To support sub-namespaces, the proposal would have to be changed such that it clearly establishes who has authority over the https://w3id.org/fep
namespace, and it would also have to use /
instead of #
in its partial term definition – in other words, define fep
as https://w3id.org/fep/
instead of https://w3id.org/fep#
so that you can resolve sub-resources.
{
"@context": [
{
"fep": "https://w3id.org/fep/",
"canReply": {
"@id": "fep:5624/canReply",
"@type": "@id"
}
},
"https://www.w3.org/ns/activitystreams"
],
"canReply": "Public"
}
Changing the partial term definition is the easy part. Establishing authority over a common namespace is the hard part. And also, once again, using a URL at all means you depend on w3id.org staying up forever (and maintaining control over it). Otherwise it’s no different (actually slightly worse) than using a URN in the first place (because of DNS/hostname authority).
Yes, it’s nice to be able to take property names verbatim and resolve their definition. But this requires domain authority. Whereas, with a urn:publicid
, there is no authority. I should note that urn:publicid
is inspired by XML public identifiers, and the urn:publicid
defined in RFC 3151 basically allows translating arbitrary strings into URNs. For our purposes, the public identifier fep:5624:canReply
contains enough information to both specify a name without collision, as well as find the associated specification and definition ourselves (by searching for FEP-5624). Can you do this with a URL? Sure, if you’re willing to claim the necessary authority and responsibility.
So, if we’re willing to claim that necessary authority and responsibility, I think we should do so in a way that doesn’t expect consistency among every single FEP. Specifically, I would be opposed to URLs of the form https://w3id.org/fep#canReply
, preferring URLs of the form https://w3id.org/fep/5624/canReply
which clearly preserve the lineage of each term definition. Or, alternatively, we have to work out the rules on requesting that certain property names be adopted as term definitions under the common FEP namespace (so that once a term like canReply
is “used up”, future FEPs know how to proceed regarding changing this definition or otherwise proposing a new term).