What is a minimal subset that would allow us to treat the @'context object as a set of extensions rather than a set of processing directives while still remaining useful?
Basically, you could have a "mastodon postprocessor" with all of the logic there.
I have a bunch of thoughts and have validated some, but I'm interested in the experience of those who have banged their head against this problem. Any ideas? Does that make sense as a goal?
I am looking for a few people who would be willing to review my (WIP) JSON-LD Reduced #FEP.
It's a little rough right now, but really I need to get others eyes on it if I am going to make any progress on it and I've been sitting on it long enough.
The basic goal is to make it so that you can use JSON-LD's context as a list of extensions and reduce the processing complexity, without actually breaking anyone who chooses to adopt it.
As I read through the discussions around the creation of and revisions around #RDF three things are clear in my eye.
Usability was not the primary concern. It seems to have been widely believed that Other Tools™ would fill this gap and that RDF should focus first on a kind of expressibility.
Those Other Tools™ never materialized.
Most who use RDF-derived tooling seem to assume either that it gives them those tools or that Others™ will build them on top of their solution as well
No. But it does mean that if you are going to use it you need to layer on top of it some additional set of restrictions.
You could easily say, for example, that "tag must always be a list/set/bag of links" (or whatever), imposing a syntactic (a list) and semantic (links) restriction.
You could say "Create must always include the full object, adjusted for permissions, Update must always be just the URI referencing the object."
As much as I dislike #JsonLD for this use case (and oh can I tell you about why I dislike it for this use case), I actually think in many ways #ActivityPub would be better if it went all-in with it.
Because right now I can't use any of the features of JSON-LD that make it actually powerful, but I've inherited a lot of the problems with the worldview.
HTTP is similar (except I don't hate it for this use case): by not committing we end up in a half-state. Neither fish, flesh, nor fowl.
As I've gotten more experience as an engineer I shifted pretty heavily toward opinionated designs, systems, and procedures.
A strongly opinionated system is more often a delight to work with—or if I can't work with it to know that ahead of time—than something that tries to make it so that it fits everything
Java is an interesting language for a Fediverse project because it's the one language with several mature implementations of Semantic Web tech (RDF, SPARQL, etc). JSON-LD just works, out of the box. It was kind of shocking to see Apache Jena do in a few minutes of work what took me weeks in Deno!
And I learned about a piece of the Semantic Web ecosystem I wasn't familiar with before. Have you heard the good word of OWL?
Really my toy #JsonLD project is a "dissent and commit" project from me.
I don't like JSON-LD, I don't actually think it is the way forward except in a very narrow sense, but I also don't think we will succeed in getting rid of it and protocols like #ActivityPub are too entrenched and too necessary for what I want to see of the internet in the long run.
So I have questions about can we make production ready systems—by my standards—that rely heavily on JSON-LD features.
Actually, I think what bothers me most about #JsonLd is that it completely misses the point of having specs and standards in the first place. Specs and standards are coordination. The whole point is to clarify, define, agree, and document things so that coordination costs stay linear, at worst.
Json-ld just says nope to that, and instead tries to replace coordination with computational wizardry. In my experience so far, it works as well as you might expect.
I'm excited to share a little thing I've been working on!
Over the past few months, I've been studying the various #ActivityPub OSS projects that are based on #DotNet / #CSharp. This started as personal research - I wanted to see how everyone else is tackling the unique challenge of implementing ActivityPub (with the oddities of #ActivityStreams and the structural incompatibility of #JSONLD) in a strongly-typed language like C#. It ended that way too - I got some ideas and moved on with my project. But I was unhappy with the overall state of .NET ActivityPub implementations, so I decided to continue the research in hope of encouraging development in this area.
As of yesterday, I've finally reviewed the very last project that I'm aware of. And to share those findings, I've put together a little website / index thing with information and links to all the project repositories. Its simple, its basic, but I hope its useful to the other #FediDev peeps out there!
You can get to the webpage itself at this link, and I welcome feedback, corrections, and contributions on GitHub.
I plan to do a bit more work on this, particularly to implement a search function. But I decided to go ahead and post it now because it turns out that there are way less of these projects than I'd hoped. :blobfoxsad:
I've been toying around with a mental model that the way that #JsonLD tends to work on the #fediverse for a lot of the major implementations I'd describe as "JSON-LD for thee and not for me."
Because they will do things like write out large contexts, but then never read contexts to know what they are looking at.
If you are the 800 lbs gorilla you don't need JSON-LD.
If you are not the 800 lbs gorilla you are playing "wackamole driven development" and need to at least read it heuristically
Ranting: I'm really growing to despise some of the features around how #ActivityPub interacts with #JsonLD, not because you "need to parse JSON-LD," but because of the JSON-LD worldview.
For example, let's look at the tag item on the Actor object.
Yes, I am probably going to be ranting about the union type problem in #ActivityPub/ #JsonLD more than usual at least until I get this serialization pattern worked out…
…or until I decide to just chuck it all out of the window and only write or accept one format.
all JSON-LD documents that's supposed to "represent" an actor must contain a single root node, when interpreting the compacted and expanded JSON-LD.
The only thing that I'm not sure of is whether the ID of the object that represents the actor should absolutely match the URL from which the JSON-LD document was retrieved from.
Mastodon will refuse to pull up the profile of a user that has its root-level node's ID not match the URL from which it was loaded from.