Re: Review of Linked Data Notifications

On 2016-10-19 06:59, Kjetil Kjernsmo wrote:
> Dear Sarven, Amy and the rest of you,

Hi Kjetil, pardon the late reply.

> I read the Linked Data Notifications spec on the first leg of my flight back
> from TPAC and wrote an implementation of the discovery stuff in it on the
> second leg. My general impression is that the spec is well-written and
> easy to understand and easy to implement. If I weren't offline in the flight
> and lacked some docs, I think I would have implemented a full receiver
> too, except for the JSON-LD part, since we haven't got JSON-LD support in
> Perl. I had planned to write my review after the implementation, as issues
> tend to pop up after implementation, but unfortunately, finding that couple
> of hours is non-trivial now, so this is what I have to offer to the WG: :-)
>
> As a general comment, I would have done the whole thing differently, I
> would have decoupled it from HTTP, and I wouldn't have had a preference
> for an RDF serialization. But that's just me, I hold in high regard those
> who write the code, and so if I wanted to make that point strong, I would
> show it through running code. I certainly do not want to delay the work
> you do with these ideas any further.

All good feedback, thank you.

I can share some of the whys in our design choice.

Not having a preference for an RDF serialization implies that every 
actor (sender, receiver, consumer) has to be able to handle all RDF 
serializations. The simplest design is to pick one where they can all 
commit to. Implementations that speak all RDF serializations will play 
along, and new implementations will have the lowest barrier for entry. 
We picked JSON-LD only for some convenience to client-side (senders and 
consumers) implementations. Not due to any particular fascination with 
JSON-LD itself :) From the Social Web WG's point of view, JSON based 
serialization is also a requirement - although I don't know how strict 
that rule is, there may be exceptions..

> My only substantial comment is an editorial comment on how to express the
> discovery that senders and consumers do,
> https://www.w3.org/TR/2016/WD-ldn-20161011/#discovery
> I think it would be clearer if it was reformulated to say something like
> "both must be tried before the sender or consumer may conclude that no
> inbox is present"
>
> KUTGW!
>
> Cheers,
>
> Kjetil

There are exceptions to trying both e.g., the inbox of a non-RDFSource 
will only be found through HTTP Link, and naturally the inbox of a 
resource with a fragment will only be found through the body.

If I understand your decoupling point earlier, I'm not sure if it is 
that necessary to do so. The general point is that any IRI may have an 
inbox, and their inboxes may be discovered by different methods. Once 
the desired target is determined (for whatever criteria) implementations 
can find their inbox with some certainty. I hope :)

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

Received on Tuesday, 25 October 2016 08:25:59 UTC