Here’s an idea. Why dont we take a version of existing software. Maybe mastodon. Then make it 100% linked data compliant. There would be a few changes, but not many. Then see what breaks if anything.
In theory the standards compliant versions should all work with each other. And then we can establish what doesnt work with the existing software, which could lead to creating upstream patches.
in general the assumption is one item per document (each doc represents an item), and link to other data docs. if this were a problem, then we might seriously consider working with flattened form and @graph.
I appreciate your perspective, @trwnh . However, I believe it’s essential to consider the broader context of web architecture interoperability. If we were to work solely with one item per page model, we might inadvertently limit our ability to cooperate seamlessly with systems that don’t make the same assumptions.
Web architecture is built on a foundation of shared standards and protocols that allow disparate systems to communicate and interoperate. By strictly adhering to these established principles, we ensure that our solutions can interact effortlessly with any other systems following the same guidelines. Consequently, while the adoption of multiple objects on a page might present some challenges, it is a cornerstone of this interoperability, promoting wider compatibility and the exchange of information across diverse platforms.
Therefore, while considering the use of flattened forms might be beneficial in certain contexts, we should also weigh the potential trade-offs in terms of overall web interoperability.
That’s certainly a good summary of JSON-LD.
If we say “this standard uses JSON-LD”, then it is very reasonable to expect implementations to understand JSON-LD.
As a matter of fact, what ActivityPub currently says is, put somewhat polemic: “we use a well-established standard, but you don’t need to follow it. If you enjoy a REST API more, well, use it like a REST API. Or whatever you want.”
That contradicts what you say about shared standards.
If ActivityPub is JSON-LD, heck, then live with it and speak JSON-LD already, period!
(Sorry, but… it must be said.)
Indeed. Part of the issue is that AS/AP had some roots in OStatus and openmicroblogging. When adopting Linked Data, they chose to diverge, hoping to gain from not adopting JSON-LD fully, possibly by prioritizing JSON or by diverging in other ways, considering some RDF aspects as excessive.
However, the outcome was a somewhat ambiguous state, leading to years of clarification and cementing some patterns so firmly that they’ve hardened over time. Consequently, the fediverse largely only interoperates within its circle and occasionally struggles even there.
While this has provided a decent starting point, I am hopeful that carefully selecting superior elements from the standards will pave the way for increased scalability, extensibility, and interoperability.
this assumption is already broken in some cases with e.g. how mastodon handles the publicKey node – some softwares like gotosocial will have a separate document for the key, but mastodon will not. mastodon’s position is that you should parse every single node in the as2 document until you find an id that matches exactly.
the point being: it’s absolutely not a requirement to have one subject per document, but it is “good practice” to do so, in order to allow fetching that node separately. working with fragments is not as straightforward as working with proper uris (as fragments are not sent with HTTP requests). there’s also nothing stopping you (the server) from embedding one document inside another document; JSON-LD allows for this, for example. JSON-LD 1.1 (there’s also “included nodes” JSON-LD 1.1 which isn’t exactly relevant to AS2 but might be worth looking at)
AS2 is not JSON-LD; it is a specific profile of JSON-LD that allows reading it as plain JSON. in other words, it is “JSON-LD that has been compacted against the normative activitystreams.jsonld context, without overriding any shortname term definitions contained within that normative context”. so if you are not using any extensions, you can just use the shorthand names set by AS2-Vocab. unfortunately, extensions are not sufficiently specified – it is recommended that you SHOULD use LD if you care about extensions, with the understanding that “plain JSON” consumers will likely ignore all of your extensions.
Mastodon is correct here, and gotosocial may limit itself. Or let me phrase it differently. With such a strategy mastodon can interact with the whole web, and gotosocial can only interact with gotosocial and others that have its somewhat insular policy.
That’s a good thing. There is more hope for interop then.
Its one like of code to grab a fragment. Fragments are sent in the payload.
You can have that easily by setting the vocab to urn:json:, you dont need to throw away semantic interop.
It sounds to me right here that Mastodon seem to be the most standards compliant. Perhaps we should just clean that up. I am intruiged by vocata too. I predict that the first instantce in the fediverse to handle fragment ids with semantic interop will have a big competitive advantage.
Actually #me is already in the spec:
https://rhiaro.co.uk/#amy
Examples 11 and 13. So fragids must be supported.