A namespace for things defined in FEPs

Ok, now understood.
Let’s stick to your example and avoid a few misconceptions, so I’m adding my “assuptions”:

  • We want to extend the type "Video".
  • The Community voted for the FEP process to do so
  • One type Video can be extended by many FEP
  • Each implementation has a different "@context"

Your example would now put a “constraint” in the FEP-process saying
“The community has already voted how to use framesPerSecond in Video, either specify it as another name or use the available definition.”

To stick to this concrete example, I would then never use this extension.
Why?
My personal opinion would be that “framesPerSecond” should always come from the most authorative source. This is the camera which produced the Video. This camera (most modern cameras) but also modern Video Editing software will store it as Linked Data already in the property xmpDM:videoFrameRate.
These things coming from devices are from the exif, IPTC and XMP namespaces.

short history: The old namespaces were for metadata for image coming from device (exif) and editor (iptc), both had different standards bodies and for Video it was even more. The “Extensible Metadata Platform (aka ‘xmp’) Consortium” formed. By the time they worked closely together with W3C LD working groups but with own specs.
Each namespace is well documented but I am recommending the Overview Page first.

So, there is mostly no need by the user to specify it then, except choosing to change the fps with your software.
The “industry” choosed to use xmpDM and produces the devices, which means, cameras may write fps in e.g. native EBML/matroska or mp4 metadata and in LD it ends in xmpDM:videoFrameRate
This is the only source from devices.
The framerate is a metadata-piece which has to be in every video.
Technically you can destroy the XMP bag and the file is fine (bag = nicer word in IPTC/XMP for LD-Container).
But this will not delete the info in the file. Things like width, height, codec, framerate are needed to make a video a video. If you delete these bits, you destroy the video-file.
But otherwise we should give user control over metadata as described in would-media-captioning-make-a-good-fep
After writing I will go on with GitHub - redaktor/mediaproxy: A proxy to cache media and deliver ActivityPub markup -
this is the building block like in mastodon or peertube to cache media from different sources or to resize, stream etc. it. But it can do a ton of things more cause it has content-negotiation. Had described it for Will here ← this example is for Image but we added the Video part meanwhile and cause Framerate is mandatory it would be in xmpDM:videoFrameRate cause as you see in the source we parse the following filetypes bit by bit mp4, mkv, mov, 3gpp, 3gpp2, enc-isoff-generic, jp2, mj2, quicktime, vnd.dvb.file, webm, 'x-m4a' and 'x-m4v', 'x-matroska', the few new Apple formats are in work, so we have fps from every favourite webvideo type but as it is used by the player.

Anyway, I would more prefer to have an option like
{"type": ["Video", "asExt:FEPxxx1Video", "asExt:FEPxxx2Video"]}
so that FEPs can live independently.

Which do not support it?
If they do not support multiple type, it is not ActivityPub at all.
If they do not support some of the type, it is fine as long the ActivityPub type(s) are supported. But I choosed the example cause if I understood correctly in “Common Domain”, you proposed to use sioc: to describe our systems.

For things that do exist already, I use existing namespaces, like schema.org. For my own extensions, especially the ones that replicate some VK-specific functionality, I define them in my own (https://smithereen.software/ns#) namespace.

But then, for private/closed groups, I find myself using my namespace a lot. There’s a property that defines the access type of the group, and it’s called sm:accessType (can be open, closed, private). There’s an endpoint that gives you a token to fetch objects from other instances, and it’s called sm:actorToken. I also use sm:TentativeJoin activity type for my events.

But then, also, a closed group has as:manuallyApprovesFollowers set to true, and in general works like a Mastodon user that manually approves followers. And you can’t even get the actor of a private group without being invited to it.

But what is the type for the Public Appendable Collection described in FEP-400e ?

The scope is https://www.w3.org/ns/activitystreams#Public and you described properties from https://smithereen.software/ns# with sm
so, can we have a type?
Like
{"type": ["Collection", "sm:PublicAppendable"]}
?

fwiw it’s more like “sm:MembersAppendable”.

We actually do need to express some permission metadata, however object types are not permissions and we probably shouldn’t confuse the two, because it doesn’t scale. We can express very rich permissions structures. For example, “Harry (not-moderated) and Meghan (moderated), but not William or Kate can append to this collection until after the 3rd of May, whilst Elizabeth can append to it without restriction”.

I’m merely trying to avoid painting oneself into a corner.

@grishka Also I would just like to give an answer to people asking how machines should refer to it.
So, meanwhile you said, ns is https://smithereen.software/ns# with sm.

And it is a specialised type of Collection. like in examples of the specification
But there is no name specified yet.
Just in the headline of the FEP “PublicAppendable”

So: https://smithereen.software/ns#PublicAppendable ?

PS: Tue meeting was supernice, there is another meeting today.

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:)