Default frame/context for the description resource

[jaxoncreed]

Currently the description resource is described to require different fields like id, subcription, and channel (https://solid.github.io/notifications/protocol#description-resource-data-model).

That's all well and good, but under the hood, the way we get fields formatted in this way from RDF is through JSON-LD context and frames.

I think we should require that the description resource MUST use a certain context/frame. Right now, the spec specifies "https://www.w3.org/ns/solid/notification/v1" as a context, but this may not be appropriate. The description resource contains more information than just notifications. It might contain information about when a document is modified or its format.

So, perhaps creating a new, single context for the document is required.

Alternatively, we could specify that it is the responsibility of the Discovery Client to parse unframed JSON-LD. This would mean that we don't need to specify a context/frame, but it would be more work on the part of the discovery client, so I would say this is less preferable.

[elf-pavlik]

We had a related discussion in #105 which led to #122

[csarven]

The Description Resource could have its own context when needed but that is deemed to be out of scope for the Solid Notifications Protocol. That falls under Solid Protocol or POWDER-DR.

The Description Resource (and the Storage Description Resource) can include multiple contexts, one of which would be notification/v1 for conformance with Solid Notifications Protocol.

Despite the naming, Description Resource Data Model is not limited to Description Resource in that information pertaining to discovering notification services/channels could be part of any resource or graph. The Solid Notifications Protocol is not defining the data model for Description Resource as a whole but rather what it needs to describe in order to set conformance with Solid Notifications Protocol.

[elf-pavlik]

@jaxoncreed are you planning that the discovery client just handles the Description Resource as plain JSON? I would suggest treating I as RDF from the beginning if used in Solid the application using that discovery client should be able to provide it with either Turtle or JSON-LD parser.

If we ever want to treat something as just JSON, we most likely need to work on the broader issue https://github.com/solid/specification/issues/454

[jaxoncreed]

I assumed that the description resource would be the format specified in the specification as plain JSON. The discovery client can treat it as raw RDF and do the parsing itself, though I think that should be reflected in the specification because as written, it describes field of a JSON object, not predicates of raw RDF.

[elf-pavlik]

I agree, let's bring up this issue tomorrow during the meeting.