I think it’s not correct when #ActivityPub thought leaders consider JSON-LD a schema definition language.
-
Nik | Klampfradler 🎸🚲replied to Evan Prodromou last edited by [email protected]
-
-
Nik | Klampfradler 🎸🚲replied to Steve Bate last edited by
-
Steve Batereplied to Nik | Klampfradler 🎸🚲 last edited by
-
Nik | Klampfradler 🎸🚲replied to Steve Bate last edited by
The JSON-LD context is a link to a schema. It really is. That's its definition. Exactly that and nothing else.
It does not assume the schema definition language used to define the schema, though. Currently, the AP context points to a RDFS vocabulary defining the schema.
The $schema in JSON Schema is a link to a schema. The only difference to JSON-LD's context is that it imposes a specific schema definition language, and one that is fundamentally incompatible with the web.
-
Steve Batereplied to Nik | Klampfradler 🎸🚲 last edited by
-
Nik | Klampfradler 🎸🚲replied to Steve Bate last edited by
-
Nik | Klampfradler 🎸🚲replied to Nik | Klampfradler 🎸🚲 last edited by
Having plain JSON and a JSON Schema definition means there is one final schema definition, and all extensions would need to fork the schema into a new protocol. JSON Schema allows for extensions only by allowing unknown fields that are not defined by a schema.
We should not do that. It's a bad idea for a federated protocol.
-
Steve Batereplied to Nik | Klampfradler 🎸🚲 last edited by
-
Nik | Klampfradler 🎸🚲replied to Steve Bate last edited by
-
-
Evan Prodromoureplied to Evan Prodromou last edited by
-
Nik | Klampfradler 🎸🚲replied to Evan Prodromou last edited by
I can very well live with that.
I don't agree with "it will just work" because we see in the wild that it doesn't. And it can't, because two AP implementations can put identically named fields in their JSON with entirely different semantics, making two proprietary protocols that are incompatible.
A single implementation can ignore JSON-LD. Two interoperable implementations can't (if they don't happen tosupport the exact same content types).
-
Evan Prodromoureplied to Nik | Klampfradler 🎸🚲 last edited by
-
Nik | Klampfradler 🎸🚲replied to Evan Prodromou last edited by
It does work because everyone and their dog copies Mastodon's proprietary, underspecified extensions that very much **do not work** without reverse-engineering Mastodon.
What Mastodon does is the basis of the practically usable parts of the Fediverse, which is far from the basis being a well-defined, extensible protocol.
All of which is because people mistake JSON-LD for JSON.
-
Nik | Klampfradler 🎸🚲replied to Nik | Klampfradler 🎸🚲 last edited by [email protected]
The AP standard as it stands allows to ignore JSON-LD in a very dangerous way. It dictates that the AS namespace must be in the context, but that's all.
All fields that are not specified in the AS context can be freely invented, and people do so. If you read the result as RDF, you get properties that look like they belong to the AS vocabulary.
That's completely broken by design.
The obvious fix is to include the nee
w fields in the context. Because, well, it's JSON-LD after all -
Evan Prodromoureplied to Nik | Klampfradler 🎸🚲 last edited by
-
Nik | Klampfradler 🎸🚲replied to Evan Prodromou last edited by
-
Evan Prodromoureplied to Nik | Klampfradler 🎸🚲 last edited by
@nik @steve why would we want to prevent ourselves from using a good, popular extension because it doesn't check a box on this best practices doc?
For example, the miscellany vocabulary documents and provides a context for some widely-used extension terms from when AP was first standardized. They all use the AS2 namespace, which is unfortunate and not recommended, but comes from their history.
-
Nik | Klampfradler 🎸🚲replied to Evan Prodromou last edited by [email protected]
Because those who have power can ignore the whole spec, force their unspecified extensions on us in practice as Mastodon does today, and still claim full compliance because all the criteria are SHOULD.
The ActivityPub in the wild today is mostly governed by Mastodon. The new draft does not solve this issue.