Re: Should the specs be forked and maintained elsewhere?

čt 23. 3. 2023 v 23:57 odesílatel a <a@trwnh.com> napsal:

> > 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.
>

Thank you so much for providing such an in-depth explanation. I would like
to examine this further and see if a workaround can be found.

I suggest that, rather than expanding "term" to `_:term` or a bnode, as
this doesn't seem helpful, we could instead extend it to urn:json:term
since the term is apparently "just a name" in the JSON context.

I have been exploring this concept for an extended period of time, going
back to original JSON-LD proposals of 2011:
https://lists.w3.org/Archives/Public/public-rdf-wg/2011Mar/0565.html

I am hopeful it would be possible to figure out a potential solution, that
would allow developers to utilize both JSON and JSON-LD, according to their
respective trade-offs

>
>
> 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.
>