white-gecko / 2016-08-29-ldn-colloquium Goto Github PK

The slides are great, thank you. Feedback on the slide with discussion / questions:

Why using exactly JSON-LD as default and not any other RDF serialization?
Why do all participants MUST support JSON-LD?

In order to have interoperability between the participants (senders, receiver, and consumers), the specification has to either specify each RDF format or say that they must support all RDF formats. If one participant supports one of the formats and the other other doesn't, there is no interoperability. The specification uses JSON-LD as the bare minimum for all participants so that discovery and delivery works for everyone. Requiring the participants to support all RDF formats is a higher requirement. Participants can support additional formats if they wish and they can negotiate among themselves. Side reasons: JSON-LD could "get away with" a JSON parser, whereas having an RDF parser is more expensive. The WG in which this spec is pushed through requires a JSON(-LD) based syntax.

Why should the payload replicate and contain the complete notification resource and the references information? Why not build links and reference it?

The specification doesn't set any restrictions on the notification payload. The sender is free to include any information they deem to be potentially useful or interesting for the receiver as well as consumers. If the receiver sets a constrain on the Inbox so that the notifications meet that criteria (e.g., see SHACL), that's their call. They might do this to filter information or to have some integrity. A notification is a message without boundaries (vocabulary and shape agnostic in and of itself).

“Decoupling between applications and data storage“ (4). Maybe also the tasks of the services and the different kinds of data storages can be decoupled.

Senders, receivers and consumers can all be implemented independently; implementing one does not require either of the others. Beyond that, there is no restriction or requirement from the applications and services beside discovery and delivery.

Why restrict the protocol to LDP and not also allow the resources to e. g. be managed by a SPARQL 1.1 endpoint?

LDN receivers mimic a subset of LDP behaviour, however it doesn't require a server with LDP. With SPARQL Update, it is not entirely clear that the resource is necessarily accessible, i.e., a deferenceable HTTP URI, even though a graph is inserted into an RDF store. In LDN, the affordances are clearer because the server gives a confirmation that a resource (with given payload) was created, and where it can be accessed.

For managing notifications once they have already been created, this is out of scope of LDN.