Re: 🔔 Linked Data Notifications: Call for feedback and implementations

On 2016-11-07 11:19, Albert Meroño Peñuela wrote:
> Hi Sarven, all,
>
> I found the LDN spec very interesting, elegant and necessary. So the
> right thing to do was to spend some fun time working in two
> implementations :-) (see [5]):

Thank you!

Can we get this gentleman a drink?

> 1. Linked Edit Rules [1], a Linked Data based solution to check
> consistency of Linked Statistical Data, is now a compliant sender. LDN
> inboxes are now discovered according to the standard draft, starting
> from a URL specified in the config file. Then that inbox is used to send
> the Linked Data content of the LER consistency reports as LDNs. Now we
> can stack all inconsistent data cubes of the Web in a machine readable way!

Coming from the statistical LD angle, I think this is a very substantial 
contribution to the field. I can't recall right now if and how any of 
the SDMX specs cover this use case, so there is also that. It sounds 
like an important intermediary between two dataset releases, since it 
provides a way to track proposed changes. Really exciting for the 
SemStats folks. Thanks.

I've updated the Overview text to include "a scientific observation" as 
a UC. Hopefully that somewhat touches on your UC.

One other thing: I think that your implementation is the first one that 
I've came across dealing with provenance/changesets.

> 2. Wrote a pythonic receiver, pyldn [2] (read "pieldon"), because there
> must be one right? An instance is publicly exposed at [3]. It uses
> rdflib to keep all notifications in separate graphs in memory, so as
> soon as you reboot the server, everything is dropped. It also responds
> to GETs to the notification URLs, it wasn't clear from the spec whether
> receivers must do that.

I curl'd [3]. Looks good!

> Actually that last bit is one of my 2 comments about the draft:
>
> - In the way it's written now, it seems implied that answering to GET
> requests against the notification URLs is not a responsibility of the
> receiver, but something the consumer "does". It's not specified what
> must happen in the other end. The behavior of receivers wrt requests on
> notification URIs is a bit underspecified and ambiguous in 3.3.2 (e.g.
> whether notifications should be named graphs). I've created an issue at
> [4] to suggest an editorial change.

You did it right. I guess this bit "Each notification must be an RDF 
source. If non-RDF resources are returned, the consumer may ignore them" 
is sort of implying that the receiver should make the notification 
available. But I agree, we can improve that wording. Thanks for the issue.

> - I personally find the two-step inbox URL discovery by senders a bit
> over constrained. The first option (rel links in the headers) seems way
> more interoperable and clean than requesting RDF content. With all the
> serializations that this implies, senders must deal with a ton of
> content negotiation that I expect only very rarely to happen (i.e.
> inboxes announcing themselves only via RDF body responses and not in
> link headers). I gather though that for general IRIs to be inboxes (e.g.
> those containing # and ?) this is necessary. Exploring the use of ? to
> send queries to inboxes
> (e.g. http://example.org/inbox?query=select+%2A+where+%7B%3Fs+%3Fp+%3Fo)
> would be interesting, but beyond the scope of the spec, I guess.

Only JSON-LD is a MUST. The rest can be negotiated if both parties agree.

HTTP Link header only doesn't cut it especially if we want to permit any 
IRI to have its own Inbox. IRIs with fragments for instance can't work 
through the headers since they are not sent to the server. From the 
other side, Inboxes of non-RDF resources can only be discovered through 
the HTTP Link header. So we need both. The thing is, while sender and 
consumer implementations MUST support both discovery mechanisms, there 
are exceptions to when to use only one (given above examples).

> - Although LDN inboxes pose an interesting use case for SHACL and other
> constraint languages (i.e. Section 5.1), for simple server restrictions
> this might be a bit of an overkill. E.g. would be nice to announce
> receiver maximum payload size via HTTP headers instead.

Constraints are challenging, and we didn't want to impose a particular 
method for all receivers to use. There are many variables if/how a 
receiver wants to do that, so it is better that they figure this out for 
their environment/data. Also, by not specifying the kind of constraints 
or how to discover and apply them, we are making it possible for future 
specs to fill in this gap, and so existing implementations can extend 
theirs arguably with less changes while still being conforming to the 
LDN spec.

> Thanks for the fantastic work!

Thank *you* for the fantastic work! :)

> Best,
> Albert
>
> [1] https://github.com/albertmeronyo/linked-edit-rules
> [2] https://github.com/albertmeronyo/pyldn
> [3] http://pyldn.amp.ops.labs.vu.nl/
> [4] https://github.com/w3c/ldn/issues/60
> [5] https://github.com/w3c/ldn/tree/master/implementations

-Sarven
http://csarven.ca/#i

Received on Thursday, 17 November 2016 10:23:18 UTC