A namespace for things defined in FEPs

Agreed, likely starting with having a peek at schema.org as most authoritative …

Best-practice: Use the most authoritative ontologies to define new types and properties in FEP specifications.

  • But there are 1,000’s of ontologies and for common AS/AP interop they likely not be fully supported, but subsets are.

I am really wondering how to make an intuitive mechanism for FEP extensions, and one that places as low barrier on any dev to follow it.

  • A FEP is a clear specification document, and should follow a consistent template to guide implementers along.
    • FEP explains in words, examples, possibly diagrams both the message formats and heuristics (business logic) of an extension.
    • FEP must be accompanied by a JSON-LD @context document for any additional properties and/or types it defines.

The example of @Sebastian contains additional Video types to define XMP/IPTC metadata, and @grishka mentions app-specific extensions where some of them may be candidates to be standardized in a FEP (but maybe not all of them).

That wouldn’t be intuitive to me if I received such message, as the additional types are non-descriptive. I’d have to go to the FEP website and look up what they are about. If you want to know what FEP’s are applied, then that could be in the app-specific @context of the message.

(Note: In the following I’m just speculating on the concepts as I lack the experience, so it may not be proper way forward)

If the FEP only specified additional properties it might look like this:

{
  "@context": {
    "sc": "http://schema.org#",
    "xmpSubset": "https://w3id.org/activitystreams/extension/fep-xxx1.jsonld",
    "iptcSubset": "https://w3id.org/activitystreams/extension/fep-xxx2.jsonld",
    "videoFrameRate": {
      "@id": "xmpSubset:videoFrameRate",
      "@type": "sc:Number"
    },
    ...
  },
  "type": "Video",
  "id": "...",
  "url", "...",
  "videoFrameRate": 60,
  ...
}

If the FEP defined additional types it may look like this (with more intuitive naming):

{
  "@context": {
    "sc": "http://schema.org#",
    "videoMetadata": "https://w3id.org/activitystreams/extension/fep-xxx3.jsonld",
    ...
  },
  "type": ["Video", "videoMetadata:XMPBasic", "myApp:FancyMetadata"],
  "id": "...",
  "url", "...",
  "metadata": {
    "videoFrameRate": 60,
    ...
  },
  ...
}

There’s many different ways that this could be designed, and that’s something to get agreement on in the course of FEP standardization process. Things may be sliced differently, e.g.

  • A FEP that defines metadata container on any as:Object
  • A FEP defining as:Video metadata conforming to a minimum profile for added metadata
  • A range of FEP’s adding very specific metadata for specialized purposes

So in the @context you can find FEP url’s. If an implementer is using JSON then they can navigate to the URL in their browser to find the spec documentation, and if using JSON-LD they find a machine-readable context as well.

(Note that in the above examples you could also refer directly to the full XMP ontology, and use anything you want from that. That might however imho lead to too much diversity and too little common ground for interoperability among fedi apps. Hence the ‘common subsets’ defined in FEP’s)

There is really a misconception.

But there are 1,000’s of ontologies

Yes, but your software specifies whith for example exactMatch what has the same meaning or what is related or will be transitioned …

These links do not have to be descriptive. We would loose all the worlds languages then.
They are not meant for humans but for machines.
A machine looks up underlying RDF, OWL, SKOS descriptions and exactly knows what it derives from. If you use skohub it is already converted to a nice JSON LD you can work with internally. Then it fetches (mostly from cache) the description in your language for humans. The skohub videos explain this as well.
This is the way which e.g. my government and the EU does it or the library system here and if you have a look at the US Library of Congress, I would also call the URL semi-descriptive,
I mean, would a human know that http://id.loc.gov/vocabulary/relators/sht means ‘Supporting Host’ in the english language?

So in the @context you can find FEP url’s

The @context is only meant to shorten things, this does not help at all here.
Example videoFrameRate
(should be original xmpDM:videoFrameRate which cameras or convert-software writes – not humans) …
It is just the same to write "http://ns.adobe.com/xmp/1.0/DynamicMedia/videoFrameRate": 60

But my one and only question:
FEPs are .md documents - what is the URL for the Collection type FEP-400e PublicAppendable?

I disagree here. Names that are both human and machine readable are preferable, imho. Machines need very strict formats and don’t care about friendly names. A human is helped with at least some context if they see e.g. a code snippet in documention.

(If only machines mattered there wouldn’t be a need to have as:Like and as:Video, and we might have as:Cv75xR and as:T893hV instead).

Don’t understand what you mean by ‘losing all the worlds languages’. In ActivityStreams spec the ontology names are English as well, but the content can be any language. And a custom ontology may still be in a different language.

You are further with implementing Linked Data extensions to AS/AP than most other fedi devs, and besides you there are just a few others firmly on a Linked Data extensibility path. Some other devs still reject JSON-LD and plain JSON route.

It would be very good for onboarding and ‘paving the road’ to reaping the benefits of linked data, if there was more information and consensus about the extensibility mechanisms to use. More examples and documentation should be available, really, imho.

Maybe not, idk. Shouldn’t there be a way to find out what FEP’s a federated app is compliant to? This is likely not the best way to do so, I know. Another thing on the TODO-list for future fedi, maybe?

Ah yes, I forgot to add. Right now we just have FEP’s as markdown docs in a repo. They have the repo URL where you get the HTML for the spec. It might be better if they were published as html on a permalink, so that’s what I suggested in the above, where querying with a text/html contenttype would give you the spec docs.

Well, anyway, my software needs just any URL to use PublicAppendable Collection like as grishka said with the smithereen namespace {"type": ["Collection", " https://smithereen.software/ns#PublicAppendable"]} .

(or as macgirvin said rather https://smithereen.software/ns#MembersAppendable)
So, when redaktor sees a new Actor and wants to know in which Collection anybody can write.

PS: Any well known concept handles it this way, not only the cited LD sources Library of Congress, German National Library and Gov and EU but also the non-LD sources like wikidata, look at the page
https://www.wikidata.org/wiki/Q232562 this is an ugly number but if we would have named it /RuthGordon what would have happened if she changed her name?
There is sense behind this.
And then the URL tells you any details, if you look there, also what is the id in about 80 other sources …

No. I said it many times and I’ll say it again: we have to consider everything in real-world scenarios. I’m not interested in any of this theoretical fluff. I come up with a user experience first, and I build the protocol to accommodate that user experience. It is unacceptable to do it the other way around.

The fact that a given collection is publicly appendable doesn’t give your application any meaningful actionable information. The fact that the ID of this collection is in a sm:wall field of an actor, on the other hand, automatically means that:

  • This actor has a wall
  • This collection contains objects of type Note
  • This collection is publicly appendable
  • This collection is owned and managed by that actor

So I don’t see why this needs to be a thing unless you provide a concrete example of a real-world use-case where having a specialized type for a publicly-appendable collection would make a difference.

1 Like

Can you maybe point to the sm:wall definition in fep/fep-400e.md at main - fep - Codeberg.org ?
It is maybe just, we didn’t find it in the meeting …

Smithereen walls themselves are not part of the FEP. The FEP is a generalized construct for “a thing to which other people can add other things”.

To answer your question: that definition is in FEDERATION.md in Smithereen repository.

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:

  1. Formal specifications (the W3C standards et al)
  2. FEP’s (common mechanisms that extend W3C standards)
  3. 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