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: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
https://w3id.org/fep/ instead of
https://w3id.org/fep# so that you can resolve sub-resources.
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).