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

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]):

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!

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.

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.

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

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

Thanks 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


On 18 September 2016 at 15:07, Sarven Capadisli <info@csarven.ca> wrote:

> Hi all,
>
> We're working on standardising a mechanism for discovering and
> delivering notifications where the notification contents are in RDF. We
> call it *Linked Data Notifications* (LDN) [1]. Catchy!
>
> Notifications can be about anything: a personal message from a friend; a
> pingback link; a comment on a blog post; a pointer to an annotation, an
> invitation to collaborate; a calendar reminder, a changelog.
>
> The spec is currently on the Rec-track in the W3C Social Web Working
> Group, and we hope to take it to Candidate Recommendation at #TPAC2016.
> We would benefit greatly from your review, if you are interested in such
> a mechanism, and even better implementations of some part of the spec.
> It can be a sender or consumer applications or a receiver (a server).
>
> We wrote the spec around what already works in LDP, so if you have an
> LDP server it already works as a receiver (just fill out an
> implementation report). To advertise an Inbox where a resource can
> receive notifications, all you have to do is e.g.:
>
> <http://example.org/foo> ldp:inbox <http://example.net/inbox/> .
>
> We'd love to hear from you if you're interested in trying out any part
> of this, either personally or as part of a project. We'd also love for
> you to fill in a receiver implementation report if you were involved
> with an existing LDP implementation.
>
> Issues are welcome on Github [2] and questions and comments on Gitter
> [3], IRC [4] or the WG mailing list [5].
>
> [1] https://www.w3.org/TR/ldn/
> [2] https://github.com/csarven/ldn/issues
> [3] https://gitter.im/csarven/ldn
> [4] http://irc.w3.org/?channels=social
> [5] public-socialweb@w3.org
>
> -Sarven
> http://csarven.ca/#i
>
>