Re: Should the specs be forked and maintained elsewhere?

Just to clarify, JSON-LD absolutely /can/ handle arbitrary JSON that's not
defined in the context. There's a couple of mechanisms to do that, one
being the @vocab mechanism (which provides a sort of "catch-all" bucket for
any undefined terms to expand into), and the other being the @json
mechanism.

On Thu, Mar 23, 2023 at 6:58 PM a <a@trwnh.com> wrote:

> > namespacing is overkill for a lot of use cases [...] If plemora and
> mastodon want to have common terms, in JSON, that's good
>
> does this actually work cleanly? my understanding was that JSON-LD
> processors cannot deterministically handle plain JSON they encounter that
> isn't defined in @context. based on the JSON-LD playground, a `term`
> without a mapping will expand to `_:term`; compaction may or may not copy
> the `term` as-is or otherwise expand it; flattening will simply assign a
> blank node identifier that replaces the `term` entirely with `b1`; framing
> will assign `_:b1` to the property name. N-Quads will completely remove any
> such statements where the predicate is not namespaced.
>
> per as2-core, activitystreams documents are defined as compacted against
> the activitystreams context at minimum, and there is this language
> regarding undefined terms:
> https://www.w3.org/TR/activitystreams-core/#jsonld
>
> > Implementations may also use additional properties and values not
> defined in the JSON-LD @context with the understanding that any such
> properties will likely be unsupported and ignored by consuming
> implementations that use the standard JSON-LD algorithms.
>
> so we can't easily depend on "just" attaching properties as plain JSON.
> unless we were to define a conformance profile spec that mandated "plain
> JSON" support, and gave JSON-LD processors extra work to do. (currently,
> the balance is the other way around; plain JSON parsers need to do extra
> work to handle things like `Public` vs `as:Public` vs `
> https://www.w3.org/ns/activitystreams#Public`
> <https://www.w3.org/ns/activitystreams#Public> being the same thing.
> generic JSON-LD consumers can handle this case trivially.) we might
> similarly imagine a conformance profile which mandated "plain JSON" *only*,
> eliminating support for generic JSON-LD parsers and only supporting
> "JSON-LD enabled Activity Streams 2.0 implementations" which special-case
> the media-type `application/activity+json` and inject the normative
> @context definition if it is missing (which in this case, it very well
> might be). anyone wishing to use flattened or framed JSON-LD would not be
> able to interoperate fully until such extension terms were defined.
>