Everybody is welcome to discuss this FEP here. Happy to hear your thoughts!
Pull Request
This looks similar to Lemmy’s Post Tags: https://github.com/LemmyNet/rfcs/blob/45796f32b9889f8177d1ac4227913262bc62887b/0004-post-tags.md
1 Like
Hi Andre. Thanks for this draft. Here’s some thoughts based on how I’m using categories in Pavillion, a FEP-8a8e compatible calendar platform. A bit about how Pavillion handles categories today:
- Categories are defined per calendar, not per instance or per application, and are translatable (a name per language). There is no fixed list; each calendar actor owns its own vocabulary.
- Outbound, an event carries the FEP-8a8e
categoryvalue, picked by an English-only keyword heuristic, alongside our own stable per-category IRIs. Those IRIs are stable but not individually dereferenceable; only the list is served. - When an aggregator calendar wants to repost events from another calendar, the curator maps each followed calendar’s categories onto their own, by hand, once per follow. The mapping is keyed on (followed calendar, source category), so the same remote category can map differently for two curators, depending on how they think about their own category system.
Overall I’m supportive of the draft and intend to adopt this model once it settles. Publisher-origin stable IRIs match what Pavillion already emits, so adoption is incremental for me. The following would be useful adjustements to the FEP based on our usage:
1. The embedded stub should carry a label, preferably nameMap. The draft says a nested Category SHOULD be a stub of type and id, optionally inScheme and exactMatch. The one thing an aggregator needs on the wire is the label: a curator maps “this calendar’s Live Music is my Music” from a list, and the list is built from labels. Without a label in the stub, the consumer must dereference every category of every followed calendar before anyone can map anything. A stub with nameMap lets a curator map any 2fa1 publisher from the event payload alone. I’d like it if the stub was revised to include “SHOULD include name or nameMap”", and nameMap should be the preferred form rather than merely permitted. A category that travels with one English label excludes non-English communities; Pavillion’s outbound 8a8e mapping is English-only precisely because the bare enum left no room for anything else.
2. State that an actor may publish its own scheme with outward mappings. In our model every calendar actor already has its own vocabulary, and small community calendars converge on a regional one in practice, set by whichever curator everyone maps to. I’d ask that the normative text state that an instance or an actor may publish its own scheme and carry exactMatch or closeMatch from it to a widely known vocabulary, so a city’s vocabulary stays local while remaining mappable.
3. Category tags should take precedence over the category 8a8e enum during transition. Implementations will emit both for a while; Pavillion already emits the bare 8a8e enum alongside IRIs, and inbound IRIs win with the enum as fallback. 2fa1 should say that when an object carries both Category tags and an application-specific enum, the Category tags take precedence, and that consumers SHOULD keep accepting the enum for a deprecation period.
4. Dereferencable IRIs should indicate when a category has been retired". Where IRIs are dereferenceable, a retired category answering 410 Gone or a Tombstone would let consumers prune cached mappings.
1 Like
Hello there! Thanks a lot. Your feedback was really helpful.
In incorporated points 1, 2 and 4 in the latest commit: The count for equivalent commits with the.
I also saw an opportunity to re-structure the FEP a bit. I moved the description of the category object (the table) above its behavior sections, and now the vocabulary is a section on its own. I hope everything is easier to follow for new-readers now.
Highly appreciated, in case you spot any further or ongoing issues, to let me know 
1 Like
Pavillion’s per-curator mappings suggest keeping the source category IRI alongside any locally mapped category rather than replacing it. A label or nameMap can help a curator choose a mapping, but matching translated labels alone risks conflating different concepts. exactMatch and closeMatch should remain distinguishable. It would be useful to specify what a consumer should retain when a mapping is unknown or a category is retired, so the original classification remains available for review.
Maybe the flow of a potential curated mapping, happening on an instance, should be layed out in the Appendix. As I read the FEP and understand you correctly what you suggested was the intention of the FEP. I thought about it that way:
At the very moment a user with the permissions to do category mappings of remote categories to local ones, wants to do a mapping the application tries to dereference the category to get a full summary/summaryMap.
When a user with permissions to provide mappings of local categories to external vocabulary, a search with suggestions based on description and labels could be available.
If you have a suggestion for an Appendix section, or I didn’t understood your idea correctly let me know!
Hi Lukas,
Pavillion does hold onto the remote category IRIs on the incoming object. The mapping process adds the re-posting calendar’s own categories alongside on the local copy of the object - only categories that belong to the calendar are shown to someone from the public looking at that calendar. You’re right that the labels/nameMaps help curators with the initial mapping, but we don’t try to do any automatic matching with them. the exactMatch and closeMatch concepts would be handy for this, but asking calendar owners to specify those for their own categories is probably too big an ask for non-technical end users.
Hi Andre,
Yes, mapping time is a good time to dereference and get the full metadata for the remote calendar’s categories. Bringing in the other calendar’s *Map fields would let the UI show the right language for the current user when they’re doing the matching. Here’s Pavillion’s current UI for doing the mapping, as an example.
Cool. Thanks for the Screenshot, always help to grasp the idea better!
The FEP ist not enforcing doing automated mappings of priorly unknown categories to local categories, at least that was not the intention. However, it specifies, once a remote category is mapped to a local one by a human, which means that is a trusted mapping, andfollow up (“trusted”) objects that contain that category, either directly or as exactMatch, this prior “human-mapping” must be applied too.
I guess the wording could be improved to make this clearer.