I’m wondering about the simple question: “When is appropriate to extend the base vocabulary? E.g. the fep vocabulary and when is it appropriate to introduce a new vocabulary?”
Case Extending Base Vocabulary
For me this would be everything that relates to the core properties of ActivityPub, like:
Extending the Actor Object with new endpoints, e.g. ServerSentEvents, or adding new attachment types, e.g. IdentityProof. These have the property that they are usable by most projects.
Adding new Activity, e.g. EmojiReact to capture reacting with an emote.
Case new vocabulary
Basically, you have something that is specific to your use case and want to create something specific for it.
Take forgefed a lot of the definitions seem directly derived from source control systems and should probably only be used in this context.
i’m not sure what you were envisioning for 2e40 but my thinking for 9606 is that the “fep” namespace is for… fediverse enhancement proposals? and therefore for the fediverse. so i guess this question can be deferred to another question: what is the fediverse?
whatever the answer, we can/should have a vendor-independent namespace for the resulting “fediverse”. this is available to any project that needs such a “fediverse”. projects that go their own way (mastodon, forgefed, etc) probably don’t need it.
I think @aschrijver captures my thoughts pretty well here with
Yes, semantics are tricky. That is why I am sceptical about a universal semantic web. A question is how to slice AP vocab extensions so they become like reusable building blocks?
We need a good common FEP (or AP/AS) vocabulary that allows all projects to communicate with each other. It is not necessary for all projects to use the same vocabulary.
I think this is also a disadvantage of how FEP-9606 is currently written. It has no mechanism to define a vocabulary in one FEP, then update it in another.
Let’s take a non-hypothetical use case. @lynnfoster wants to introduce the Valueflows as a vocabulary to use within the FediVerse. As this is domain specific, she wants to keep it separate from the common fep vocabulary. Now, there are essentially three options:
Do as she does now, and introduce this vocabulary with a context hosted at https://w3id.org/valueflows/. This has the disadvantage that there is no clear FEP label.
Use the mechanism from fep-9606, this would result in the vocabulary at https://w3id.org/fep/9606, which has little semantic meaning, and an update (in a new fep) would change the id, if I understand the mechanism correctly.
Use what I called secondary vocabulary in fep-2e40. This would lead to https://w3id.org/fep/valueflows being the relevant context.
Note: This is not an argument for fep-9606 vs fep-2e40; at most a suggestion to include the secondary vocabulary concept.
3 has another advantage over 1 in addition to fep branding: This would lead to the context just being
I really appreciate this discussion. I also know I am not up to speed with the FEP history and thinking, which I am slowly working on. So maybe a couple datapoints and very tentative thoughts:
Valueflows is used in more technical ecosystems than the fediverse, although we do love the fediverse! But VF tries to be protocol agnostic and wants to support whatever people want to do technically, now and in the future, including non-rdf-based implementations. ForgeFed for example looks much more like it is born and living in ActivityPub. Anyhow, VF needs its core definition to be outside the FEP.
But still somewhere it seems we would need to say something like “vf:Plan rdfs:subClassOf as:Object” or maybe something like “as:object rdfs:range vf:Plan”. Or whatever we end up with. Seems FEP-like.
VF references now in its spec some things that VF itself requires, quantities and locations and such, where we try to re-use. Also, we’re working on some other more peer-like integrations (vs extensions), like sensor measurements (sosa) and open hardware specs (okh).
But those feel different than figuring out how VF would fit into AP/AS. It also feels to me like VF (and perhaps domain-specific vocabularies in general?) want to use the protocol focus of AP distributed messaging more than the domain focus of social networking found in AS. Those are pretty hard to separate out atm though.
i don’t particularly see this as a disadvantage. if an FEP simply says “use this external context/vocab/etc”, then it doesn’t need to be in the context definition.
that’s not really how it would work. updates never change id. you can have a new FEP use terms from an old FEP while superseding the old FEP, if desired. if FEP-1001 introduced valueflows, and FEP-1002 added new terms, then some terms would be under the 1001 namespace and some terms would be under the 1002 namespace. but i don’t really think this is a recommended option, since valueflows exist outside of the FEP process and outside of any specific FEP.
what do you expect to be hosted at https://w3id.org/fep/valueflows and why is it important to only have one context reference instead of a context array?
FEP-d767 is “Extend ActivityPub with Valueflows”, but Valueflows is a whole ‘business domain’ of its own, with a full independent set of specs, as @lynnfoster says. So where that binds to AP it may be in multiple FEP’s.
But I just took Valueflows as an example. Could as well be “Social Video Platforms” as domain, or “ECommerce”, where you potentially have many domain-specific building blocks in separate FEP’s.
(And this was also a follow-up to the idea to have domain-specific vocab extensions be part of FEP’s in the first place. There’s also an argument to have them all be separate e.g. in their own ‘community hubs’ similar to Podcasting and ForgeFed, and have FEP’s deal with core protocol enhancements exclusively)
Note that the flat list of FEP’s is already starting to be quite “messy”, where for instance a couple of them are related to “Payment/Monetary” kind of domain. Imagine an unordered list of 300 FEP’s some time in the near future.
Yes, and solves having domain-specific conformance profiles too. The FEP content hierarchy would be different then too. I’d rather have a separate list of conformance profiles then.
I recall from ages ago I had the “ontologies” org/namespace on github. So it’s possible to put host number of vocabularies there. Yes I know we prefer codeberg, but the github pages allows you to host things for free, you can get up and running quickly and then move things to a dedicated site later.
If there’s a will to extend activity streams, we could as a group collect terms and create an extension vocabulary. This could be done very quickly with simple pull requests in a few minutes each. Alternatively, we could make a new vocab for each idea, or domain, or application space. And see what catches on. The FEP process is also good, the idea of vocabs is so that many can live side by side, and be extensible.
If anyone has pointers to new terms they want, let me know, or raise an issue. I can replace the dummy template with actual terms. I can make similar vocabs for people that want them, e.g. for the toot vocab, and do it in a way where you can on any url, and have the code where you want e.g. on codeberg.
With this infrastructure in place it could be possible to extend vocabs to many new domain areas.
there’s a degree to which context should have versioning too, because otherwise terms in the json will change their full meaning, even after they were published
This is not incompatible with the FEPs (though I need to read more), Linked Data is designed so that when you scale you can pull in different vocabs and contexts. I would like it so that it’s easy to make new vocabs and we can guide developers through it with a good devX.
Anyway this is just preliminary thoughts, I will read through all the feps and message threads that I can find.
That was my goal. Sorry, if I sounded a little bit short tempered. My current feeling is that the json-ld issues are easy to start with and extremely hard to finish. Main exhibit: I’m not done forming opinions.
@aschrijver Can you please tag this with linked-data ? I cannot edit the post myself. Feel free to delete this post afterwards. I might copy and paste this a few times.
Thanks for tagging linked data. This is a good move. I’ve iterated a bit more on asx, it’s still a very early work on progress, but I’m starting to be able to pull things together. This is an owl vocab in json-ld in the wiki for now, but I’ll have something decent soon: