@kopper @hongminhee @julian

anyway, if you like RDF and `content` is html how about RDFa ?
For us it would work similar. If we have any "convention" before we stop writing it might save time of rewriting

@sl007@digitalcourage.social eh? You use context?

ForumWG decided to use context to represent threads in threadiverse software (and Mastodon too, now).

Just FYI.

@julian

hm, strange. I would really not ignore all the official ActivityPub meetings between 2016 and 2014 Maybe it would be worth to read the W3C minutes of SocialCG 2019 ff
Think, it _should_ have been 2019 or 2021 cause 2021 it wasn't on the "waitlist" anymore :https://socialhub.activitypub.rocks/t/2021-01-09-socialcg-meeting-fep/1246

But:
It dates back to 2020 https://socialhub.activitypub.rocks/t/context-vs-conversation/578 and after mastodon and pleroma agreed to the us , the 2 Social CG meetings are linked by me in the thread.
Then we had the 2020 brilliant Conf.

So, well, we use it for ActivityPub spec says and what was decided there by all …

mastodon is _not_ able to introduce breaking changes to a W3C standard
Just FYI.

@julian

Can you specify "threadiverse" software cause like all properties which are not marked as "functional" in the ActivityPub Spec, `context` is an Array and I do not see any problem …

@julian

^ what I mean :

"context": [
"https://threadiversesoftware.example.org/thread/123",
"https://www.wikidata.org/wiki/Special:EntityData/Q64 "
];

then says:
"Hi machine, I am in the context of thread 123 about Berlin."

@julian

Is there a W3C minutes or kind of a meeting-protocol|spec. about this use of context?

@sl007@digitalcourage.social FEPs 7888 and f228 details the use of context and one use case of it, to backfill conversations.

@julian

well, but that is _exactly_ the same of the official Social CG meetings !

"This context property is the URL of the NodeBB topic."
vs.
"The context property should be used to identify the context in which the object appears in, form a common topic or group content. This can be a well known JSON-LD vocabulary or any ActivityPub Object useful for the implementation."
vs
https://www.w3.org/TR/activitystreams-vocabulary/#dfn-context :

„Identifies the context within which the object exists or an activity was performed.
The notion of "context" used is intentionally vague. The intended function is to serve as a means of grouping objects and activities that share a common originating context or purpose. An example could be all activities relating to a common project or event. “

and I am glad cause, as said
"context": [
"https://threadiversesoftware.example.org/thread/123",
"https://www.wikidata.org/wiki/Special:EntityData/Q64 "
];
then says:
"Hi machine, I am in the context of thread 123 about Berlin."

and then

🧵 1/2

@julian

and then
1) machine gets thread (cause is JSON-LD by known/allowed `generator`)
2) machine fetches or gets cached wikidata entry about Berlin and displays the card (kind of "infobox" then).
.. from the named "SpecialEntitiyData" of wikidata which is JSON-LD as well.
3) machine is happy

apart from our tools, I need to credit Max Lath who is doing inventaire, the federated book library and did a lot of previous work for wiki JSON-LD like the wonderful https://github.com/maxlath/wikibase-sdk

@julian

PS - just btw;
about inventaire I am sharing currently photobooks for free rent in Dortmund, Germany
https://inventaire.io/users/sl007
they have also nice use for JSON-LD re. books /authors etc. https://data.inventaire.io/ like so many software in fedi.
If you ask the redaktor Service Actor for Place (`Question`) to find you a waffle restaurant in Amsterdam serving blue syrup near a train station then we do also use SPARQL like them - without the AI bullshit - just cause millions of friendly humans contributing to wd and OSM …

@kopper @hongminhee As the person probably most responsible for making sure json-ld stayed in the spec (two reasons: because it was the only extensibility answer we had, and because we were trying hard to retain interoperability with the linked data people, which ultimately did not matter), I agree with you. I do ultimately regret not having a simpler solution than json-ld, especially because it greatly hurt our ability to sign messages, which has considerable effect on the ecosystem.

Mea culpa

I do think it's fixable. I'd be interested in joining a conversation about how to fix it.

@cwebber @kopper @hongminhee

I don't remember it that way.

We started the WG off with AS2 being based on JSON-LD, and I don't think we ever considered removing it.

I don't think it was a decision you made on your own. I'm not sure how you would, since you edited AP and not AS2 Core or Vocabulary.

@cwebber @kopper @hongminhee

I would be strongly opposed to any effort to remove JSON-LD from AS2. We use it for a lot of extensions. Every AP server uses the Security vocabulary for public keys.

@cwebber @kopper @hongminhee It would be a huge backwards-incompatible change for almost zero benefit. People would still make mistakes in their ActivityPub implementations (sorry, Minhee, but that's life on an open network). We'd need to adopt another mechanism for defining extensions, and guess what? People are going to make mistakes with that, too.

@cwebber @kopper @hongminhee The biggest downside to JSON-LD, it seems, is that it lets most developers treat AS2 as if it's plain old JSON. That was by design. People sometimes mess it up, but most JSON-LD parsers are pretty tolerant.

@gugurumbe @cwebber @kopper @hongminhee AS2 requires compacted JSON-LD.

There is no data format we can choose to eliminate programmer errors in online protocols. That's a quixotic aim.

@gugurumbe @cwebber @kopper @hongminhee

@evan @cwebber @kopper @hongminhee maybe a compromise approach could be to specify a simpler “json-ld as it is used in practice”, similar to what HTML5 was, that remains backward compatible while simplifying the spec to the point that it is actually feasible to implement