@gugurumbe @evan @cwebber @kopper @hongminhee yup, using full IRIs also has the advantage that ld-unaware processors only need to recognize 1 form instead of infinitely many.

the thing is, we have semantics imported from the content type (activity+json) which can also change. which is why i think versioning the context document is also important -- it freezes the semantics at the time of publishing, like pinning your dependencies.

without that, we might well have a simpler profile...

@trwnh as a paranoid person, I sometimes wonder what would happen if schema.org received a court order to partially censor its schema in certain regions of the world. Or inject a backdoor key. If it prevents people from sending memes across the geofence, it’s bad.

@cwebber @evan @kopper @hongminhee For the purpose of "message" wouldn't it then be easier to just sign an entire file that is transmitted? Or is this stream processing.

@cwebber @kopper @hongminhee If we consider data exchange just in one application context (mastodon), then JSON-LD is overhead because data structures are fixed.

But as soon as we go out of that application context, JSON-LD will make a lot of sense. IMHO, the use will grow over time as this allows to add permissions to post on the data level using ODRL e.g. Or to have privacy considerations.

On a very short term, JSON-LD may be an overhead. But it is an investment into the future.

@kopper @hongminhee @cwebber but the JSON parser will not recognize naming conflicts. We are talking about data flows beyond the application context. I see you arguing in a social-media distributed twitter context and not a millimeter beyond. That's ok

Inside that context, JSON-LD remains valid JSON and your implementation can ignore the context. But as soon as you want to annotate stuff and NOT hardcode it into your app, this context becomes important.

@kopper @hongminhee @cwebber and to know other people being really happy with JSON-LD and really needing this functionality, you need to get out of your own application context and into data flows. E.g. Trade transparency. And they may also use activity pub at some point:
https://uncefact.unece.org/spaces/uncefactpublic/pages/246317069/Verifiable+Credentials+for+Trade

Talking of kool-aid, note that I'm only the lawyer.

@kopper @hongminhee @cwebber Oh, I see what you mean. We had that (very heated) discussion in 2004 between the RDF folks and the XML folks. You're using JSON like the XML argumentation back then. And yes, it is possible to re-invent RDF functionality using JSON or XML. This was the point of the 2004 dispute. JSON-LD is only ONE way to solve those possible conflicts. It just happens to be an interoperability specification we call "recommendation".

Sorry for my misunderstanding on namespaces.

@evan@cosocial.ca Can I say something, as someone who is not technical but cares deeply about the fediverse and its future, and who read the whole conversation with great interest?

You might be familiar with the term "desire path". It's when a place, like a park, has pre-designed pathways, but people end up using their own, because they are more convenient. This is not user error - it's a design failure.

I've been hearing complaints about JSON-LD since I was in Firefish. When so many people -including even people who co-wrote ActivityPub!- tell you that it's problematic, that it has ended up not being used, that most projects find their own shortcuts (or desire paths) and we need to find a better way, telling them "you should just use it as it was designed" comes off as arrogant and short-sighted. And these are not people who work for BlueSky or people who want to see fedi fail - they are people who care so much about ActivityPub that they have studied it and built whole applications around it. It's not nice to dismiss them like that.

You have co-written and are largely responsible for something that was meant to be used by people and developers. Clearly, its core is great, or it wouldn't have been relatively successful. But if parts of it were too complicated and have not been adopted, then it's a design problem with these parts. A good protocol should be easy to work with and build on.

I don't think you should be scared of breaking backwards compatibility. This is sometimes an essential part of progress - and if something doesn't progress, it usually dies. For how long will people keep building on a protocol that stays stagnant to not break backwards compatibility? Ten years? Twenty? Yes, you don't want to make big changes very often. But never making big changes also doesn't make much sense. Especially regarding parts that are not used as intended in practice, therefore have proven to have failed. Accept it and find collective ways to improve ActivityPub, or blame everyone else for not following to the letter a spec that obviously doesn't fit well with their needs.
@julia@eepy.moe @cwebber@social.coop @hongminhee@hollo.social @kopper@not-brain.d.on-t.work

@evan @kopper @gugurumbe

I do note that you argue for backwards "Fediverse-compatibility" here, and I wonder how that equates with backwards #ActivityPub compatibiity.

@kopper @hongminhee @julian

addendum;
updated the hierarchical UNESCO World Heritage Collection with their 1247 Entry-Collections having 8000 Places.

Apart from `Content-Negotiation`
Noticed that you can also get the jsonld in the browser just by adding ".json" e.g.

https://www.wikidata.org/wiki/Special:EntityData/Q122842228.json