Hm, ok. That is unfortunately really counter-productive. Of course I can’t expect from the client, I am writing AP software for, to have a look each week which fedi software is new (currently a lot) and if they use PublicAppendable and what different namespace they use for exactly the same concept. Then we do not need a standard and everyone could just use their own namespace.
1 Like
Again, you will never see the collection on its own. You get its ID from somewhere, right?
And I still want you to answer my question: what is the real-world use case that is solved by defining a separate type for publicly-appendable collections?
Is it enough of an answer to have FEPs published this way?
This would mean: https://socialhub.activitypub.rocks/pub/fep-400e-publicly-appendable-activitypub-collections
Well,
it is a should in the specs.: #extensibility
But no problem - if it does not have a type or URL (like e.g. peertubes Playlist etc.), I can’t use it as e.g. commentPolicy or any other for the vocabulary.
While we talked a lot about how to extend, I will just leave it out the extended Vocab.
No worries !
That’s a double indirection. So you want to have the FEP url de-referencable from the @context. It points to this Discourse forum, which is a manual (and editable afterwards, but by one single member unless it is a wiki post) copy of a markdown in a git repository on Codeberg. And that url points to the top of the main branch, not a particular revision (commit), so it might change after you included it. If you take for instance the W3C specs themself, they point to the revision:
This version:
Latest published version:
Right now we have an open issue on the FEP process on how to change or extend them once they became FINAL. It may impact how to reference ‘This version’. Also we talked about stable domains to use and w3id.org and purl.org were mentioned.
Maybe the ‘This version’ would be something that includes the short-form SHA1 hash of the commit that finalized it, combined with the stable URL.
https://w3id.org/fediverse/fep-400e/publicly-appendable-activitypub-collections/eb893ae1a5
In that example the fep-400e is taken as FEP identifier and the title separate (similar to Discourse URL’s where you can omit the title), so the shortest-hand form of the ‘Latest version’ would be:
https://w3id.org/fediverse/fep-400e/
1 Like
I do not want to refer to a FEP.
I want, like all the existing solutions, just to refer to the Thing: sm:PublicAppendable.
All the major implementations have specialized Collection-types.
Mastodon has toot:featured or peertube has pt:Playlist.
We do not need to rewrite W3C specifications which were made in a year long process.
It is well defined how to extend and I linked it 3 times in the last days.
The rest of the Vocab for a common namespace is ready now, it uses all the @context which various implementors gave and from the mastodon and peertube documentation and 2 discussion items which everyone uses differently (marking DM and commentPolicy/inReplyToPolicy/commentsEnabled etc.)
Sure, but in th @context you need a namespace that defines what that prefix stands for, right?
Besides that as I’ve mentioned a couple of times before I see 3 levels of standardization with decreasing amounts of required formality:
- Formal specifications (the W3C standards et al)
- FEP’s (common mechanisms that extend W3C standards)
- AP extension vocabs (either standardized for reuse in a particular domain (
toot:ideally), or fully app-specific (sm:)
Well, forgot that.
It is (in this example) the smithereen prefix which is http://smithereen.software/ns#
As said, all the things for the namespace would be ready. We can do it prior to next meeting.
1 Like
It is interesting how the lack of clarity on how to write extensions consistently leads to ‘ad-hoc interoperability’ (everyone doing their best, but in slightly different way to satisfy their own app’s needs, and not share specs on that afterwards).
I recently wrote down some notes for myself on how the W3C standards put people on the wrong footing, and that it may be better to position ActivityPub as providing a framework instead of an oven-baked spec that you should just implement to the letter to facilitate broad interop.
And that the AP spec is actually more of a transport protocol intertwined with examples of particular extensions, most notable AS.
Sorry, I do not understand but my team and mostly me spent really much time and work for
asSkos.ttl (701.4 KB) the past days.
• There is anything inside what is currently used (at least what we got from all the documentations of all the lists or directly by coders).
• It defines the Linked Data modell with rdfs and owl and has nice human readable SKOS labels, definitions and examples in 8 languages
[only 4 languages in the posted file cause it is a problem when it becomes huge before we have singular SKOS files cause of computers w. 4GB RAM etc.]
• Implementors can use it to build forms, post interfaces, controlled vocabs. and we can even recommend suggested CV (e.g. alos told nilesh cause he is doing 1 for learnawesome)
• Users can click the terms in a structured way or discuss them
We can exactly define what is the same (so far all extensions except 2 have different reasons and meanings) and there are 2 discussion items which are the exact opposite and treated different anywhere, most important pt:commentsEnabled zot:commentPolicy mobilizon has it as repliesModerationOption etc.
It is answering “Who can reply when and where” …
However, we can’t change what was already extended elsewhere.
It is what I told e.g. NGI0 from the beginning, that they should also connect the funded ActivityPub projects.
This does not seem to happen cause my observation is that devs who meet nearly each other day somehow with the others are only the unfunded projects.
But we can use it to define future terms. For redaktor and G+J this is wikidata (already pasted) and IPTC things like rNews. And I’ll write to implementors where I know that they will introduce new terms.
I can’t say to my publishing house that we continue to use ActivityPub as a loosely coupled framework cause they already know that it is a recommended standard by the World Wide Web Consortium for federated social networking.
And if Mr. Schubert is right, Mozilla probably would not have choosen ActivityPub for thunderbird and also the Mozilla thunderbird team would not have discussed with Jack Dorsey to do the same.
1 Like
Yes, I saw your response and responde to the other toot. Tbh, I don’t think NGI0 or any other NGI fund at the moment has a mandate to fund anything beyond innovation projects. That is a bit of an issue as community work, given how time-consuming it is and the challenges that exist at this leve, really deserve attention by the EU. Maybe there are other funds that allow for that kind of support. It is not NGI0 prerogative.
It is great to have things defined in such a Turtle format, and you are really thorough in adding multi-lingual documentation to it. There are some things I wonder about, unless the asSkos file is particularly made to work for Redaktor. Namely that I do not think we should have one big definition with all custom extensions be part of it, but rather a growing list of separate extension definitions that can be either app-specific (and maintained by the related project) or more suitable for general use.
Well, I am doing what the group decided.
It is for anyone to easily consume ActivityPub together with for example the extensions for 3mio. german magazine subscribers and/or the podcast spec. and/or redaktor etc.
Extensions are optional, the core must be the entirety. I think that’s easy.
Maybe you can again explain your idea of a common domain again.
You are the first person saying, it is not needed.
unless the asSkos file is particularly made to work for Redaktor
How can this be possible?
redaktor federates.
We will go on with it in the next meeting.
The draft FEP for Content Addressable Vocabulary may be relevant to this thread.
Discussion for that proposal is here: FEP-cb76: Content Addressed Vocabulary
1 Like