Descriptiveness
I have an issue with the proposal related to descriptiveness, or rather the lack thereof. LinkedData is supposed to be both machine and human readable. Suppose on a msg I get a large @context and it references, say, 20+ different FEP’s. How do I read this context and know the meaning of these FEP’s?
Well, the FEP ID’s are semantically meaningless, so I must one by one follow the FEP namespace to find the corresponding spec and then see what they are about. Very unwieldy. In some cases property names in the namespace may be descriptive, but in many cases they probably aren’t. Consider e.g.
{
"@context":
"order": "https://w3id.org/fep/14e3/order"
}
}
What is meant by this, for example in the context of a hypothetical OpenRegulation app? Does it mean List Ordering, descending/ascending? Does it mean a Court Order ID? Or maybe an eCommerce Product ID for ordering resources for an upcoming case?
What if multiple definitions of the same property can occur in the msg? Which namespace prefix should one choose? One is free to choose anything, and there’s no convention to improve msg readibility.
{
"@context":
"order": "https://w3id.org/fep/14e3/order",
"myAppRocks:order": "https://w3id.org/fep/1a8c/order"
}
}
Linked data has some well-known open standard ontologies where conventions for namespace prefixes are used (but not enforced) e.g. schema: or vcard: and ActivityStreams has a convention of as: prefix.
The full namespace of ActivityStreams itself is descriptive i.e. https://www.w3.org/ns/activitystreams → “Ah, the well-known W3C open standard 
”
Things get less clear on vendor-specific namespaces i.e. http://joinmastodon.org/ns# → “Ah, Mastodon-specific stuff ”, but “Oh, toot: is the namespace prefix to use for Mastodon properties, or is that standard? 
”
This non-descriptiveness is bound to become more of an issue as the list of FEP’s grows, and they cover numerous different domain models and functional aspects. FEP’s are like building blocks you stack together, but none of the blocks have an intuitive name that makes them easy to remember.
Fediverse Features
@helge started the Fediverse Features project that discerns concrete chunks of functionality, names them, and tests their behavior using BDD Gherkin scripts.
This project aligns with the idea that apps stack together functional building blocks:
A FEP is a formal specification of a functional building block for the creation of interoperable apps.
Interoperability on the Fediverse is not about apps, but on finding common denominators where compliance exists.
I find that second point major important, as this realization will help give developers the proper mindset to adopt when looking to integrate their project with the Fediverse. They should be focused on which common functionality they want to federate, and not whether arbitrary app A can interact with arbitrary app B.
The naming of Fediverse Features is something that can also help in making namespaces descriptive. For instance, taking the Groups FEP it may be indicated with its fediverse-feature name of groups:
{
"@context":
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/fep/1b12/groups"
}
}
Suppose my message supports all known group-types, so also Unbound groups FEP:
{
"@context":
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/fep/1b12/groups",
{
"gs":"https://w3id.org/fep/2100/unbound-groups"
}
}
}
Note, in this example I use the namespace prefix suggested in the unbound groups FEP, but a better approach might be that besides namespaces following Fediverse Feature naming convention, they’d also have a preferred namespace prefix that is recommend accordingly, and that my be unbound: in this case.