JSON-LD structural requirements have issues

[RubenVerborgh]

No description provided.

[elf-pavlik]

In principle, it is harmful to train developers to rely on a specific JSON structure, because we have no such guarantees elsewhere in Solid.

I agree with this in general. IMO the consumer should be responsible for providing @context and frame for JSON-LD if they indeed using it as plain JSON.

While in very simple cases, where all the statements have the same IRI as subject or object (and leverage JSON-LD @reverse) I think one could get by without JSON-LD Framing. This is clearly not the case here.

So my preferences are, in order:

• To not mandate a specific JSON-LD frame or context (and to maybe not mandate JSON-LD then, as it is not meaningful in that case)

I think we should aim for that. I think we can still mandate text/turtle and application/ld+json but without putting any additional requirements on JSON-LD.

[elf-pavlik]

I was thinking of just following LDP and Solid Protocol support for both text/turtle and application/ld+json. This way client just needs one of those parsers to get handle all the data.

As I understand Solid storage doesn't guarantee that a specific JSON-LD structure gets preserved. For example in a quad store-backed CSS, creating a resource with a specific JSON-LD payload wouldn't guarantee the same structure when requesting that resource with application/ld+json ?

I'm afraid that if we start relying on specific context and frame, solid storage will be unfit for storing that data. I will probably raise this issue again for Solid-OIDC, since it seems that apps can't publish their Client ID Documents to solid storage in a reliable way.

[csarven]

There has been some updates to the spec that's formerly known as the "Notification Subscription Metadata Resource". It is currently known as the "Notification Channel Resource". The section on discovery clarifies the requirements: https://solid.github.io/notifications/protocol#notification-channel-discovery but the concerns on JSON-LD as per this issue still stands.

I agree that the spec needs a revisit pertaining to JSON-LD. I do not think we need to revisit serializations in general. I'd however be in favour of making sure things are uniform as much as possible for the notification channel resource, subscription request and response, and notification.

The following needs to be revisited:

• https://solid.github.io/notifications/protocol#server-notification-channel-resource-accept
• https://solid.github.io/notifications/protocol#server-notification-channel-resource-jsonld-context
• https://solid.github.io/notifications/protocol#server-subscription-request-accept
• https://solid.github.io/notifications/protocol#server-subscription-request-content-type
• https://solid.github.io/notifications/protocol#server-subscription-request-response
• https://solid.github.io/notifications/protocol#notification-data-model

---

I'm on board with some of the possibilities mentioned in earlier comments. Here is my take/suggestion:

The JSON-LD compacted document form ( https://www.w3.org/TR/json-ld11/#compacted-document-form , https://www.w3.org/TR/json-ld11/#application-ld-json ) should be sufficient to keep things RDF based and friendly-enough (for plain JSON consumers, if they so wish).

Essentially Accept and Content-Type headers including application/ld+json; profile="http://www.w3.org/ns/json-ld#compacted" would be something clients and servers acknowledge. If they wish to negotiate/agree on other possibilities, great. If the client uses a media-type value without the profile parameter, server responds with compacted JSON-LD.

We may also want to describe profile in the core Notification Data Model, especially considering that it currently employs AS2. We can work that out once we wrap-up the core, and describe how to extend with Notification Profiles ( #101 ).

[csarven]

Thinking more on this. I think one of our goals for this spec should be to remain compatible with the Solid Protocol. So, if the Notification Channel Resource, Subscription Resource, and Notifications (for some Subscription Types) is on a Solid server (and I think we somewhat expect that but the spec may not explicitly mandate that), the server shouldn't have to do additional work.

Regarding a specific JSON-LD serialization, I suppose while a Solid server may accept a particular JSON-LD document form (like compacted) but it may never actually use the same form in a response payload. In that case, if the Notifications Protocol requires compacted JSON-LD for example, we are asking the Solid server to do a bit more. I think it may be preferable to not ask that additional work. It should work out of the box. And so the Notifications Protocol should only say that JSON-LD is required and leave it at that.

The Notifications Protocol, or at least the core Notification Data Model must be RDF-based - I don't expect anyone objecting that, I hope - and if anything, be JSON-LD friendly. There are a couple of specs that make use of JSON-LD that can work with the Notifications Protocol. Minimal interop is already in place in some cases. I worry that if we say something other than JSON-LD, we may be complicating things for both servers and clients.

(I say this without being a fan of JSON-LD... hey, ask me what my fave is :) but trying to make the best of aligning specs.)

[elf-pavlik]

(Note that this contrasts with Solid-OIDC, where a context is added retroactively to interpret an existing already constrained JSON structure as RDF, which is the other way round.)

I re-raised Solid-OIDC Client ID Document requirements in solid/solid-oidc#95

[csarven]

Considerations/decisions elsewhere that can be useful input:

• Tracking Issue from TPAC: What does JSON-LD compatible JSON mean? w3c/vc-data-model#929
• https://w3c.github.io/wot-discovery/
• ...

[csarven]

A proposal to resolve this issue: #122 that focuses on making the requirements uniform.