These are chat archives for csarven/ldn

2nd
Jul 2016
Sarven Capadisli
@csarven
Jul 02 2016 00:15
2 is not an issue for dokieli - easy change. d can still do negotiation because it is not dependent on Solid per se.. and maybe not even LDP a little later down the line.
Sarven Capadisli
@csarven
Jul 02 2016 00:56
I think 2 is all around better, even though I don't fancy JSON-LD nor think that a particular RDF serialisation is ultimately preferable.
Sarven Capadisli
@csarven
Jul 02 2016 01:03
2 is simpler to implement or commit to for all parties involved. I think. It also puts a lot of pressure on receivers as the primary handlers of data - even if that seems intuitive at first.
I would love 1 to be the case but fear that it won't work out. Part of me wants to see LDN build on top of existing stuff and basically have anything that's already LDP compliant or whatever out there to come out and work out right away.
Not sure what hte best cost analysis is but.. (existing) receivers making sure they do JSON-LD vs. (existing?) senders/consumers handling JSON-LD. Which is more costly to change/update ? what's the count of receivers, senders, consumers.. ? (Not expecting exact answers but just some things to consider)
Sarven Capadisli
@csarven
Jul 02 2016 02:16
re 1: LDP requires receiver to support Turtle and JSON-LD
The rest is open
If Solid is LDP compliant or wants to be or cares to.. they should be on equal grounds.
(In case there is a tie on the q value, Turtle gets its way)
Sarven Capadisli
@csarven
Jul 02 2016 02:25
If I'm reading the LDP spec right, Turtle and JSON-LD serialisations of a resource MUST be available.
So, even if we just pick one of those serialisations, it is compliant with LDP. Whether it is compliant with node-solid-server or if at all in the future is open.
Sandro Hawke
@sandhawke
Jul 02 2016 02:58
@csarven LDP only cares about Turtle/JSON-LD for containers. We're mostly talking about the notifications here.
Sarven Capadisli
@csarven
Jul 02 2016 14:00
That applies to both inboxes and notifications in our case I think
Sarven Capadisli
@csarven
Jul 02 2016 14:17
@rhiaro We need to address inboxes on any resources clearly in LDN otherwise even Solid inbox is not compliant with anything for that matter... or rather Solid inbox is not doing it right at the moment. The discovery of the inbox is document centric and/or strict to profiles.
https://foo.databox.me/profile/card doesn't have an inbox. https://foo.databox.me/profile/card#me does. Remember what we were discussing on Friday: HTTP headers will only be able to reveal "document level" inboxes. So, even if /profile#me has an inbox, the header on /profile inbox will be different.
Sarven Capadisli
@csarven
Jul 02 2016 21:21

Sarven Capadisli
@csarven
Jul 02 2016 21:54
Gold and node-solid-server is able to return Turtle and JSON-LD on RDFSources (container and 'regular' resource). So, it seems to be that those parts are compliant with LDP.
Sarven Capadisli
@csarven
Jul 02 2016 22:07
At the moment, we don't say which serialisation is required for discovery of the inbox. It just says that it needs to understand an RDF Source. So, that implies that a receiver might give a serialisation that a sender or consumer can't understand. We are back to: either everyone needs to understand all RDF serialisations or we need to list which ones. The actual challenge is IMO on the receiver, more specifically the publisher. The publisher usually decides to use a serialisation that's most suitable or at least reusable for the type of data they are putting out there. So, that means that expecting a document (HTML[+RDFa]) to be also in JSON-LD is a bit awkward if we say that JSON-LD is a MUST to discover an inbox. Similarly, we can't expect a single serialisation to take full control.
Using the Link header to discover inboxes appears to be a workaround for the serialisations, however, that sets a limitation which is not "Linked Data friendly" IMO. What that essentially means is that the discovery of inboxes is limited to URIs with no fragment.
Sarven Capadisli
@csarven
Jul 02 2016 22:13

Sarven Capadisli
@csarven
Jul 02 2016 22:20
I don't want to give up on the idea that any URI can have an inbox. This is important I think. So, if that means that inbox discovery can't work out consistently across implementations if we use Link header (because a conforming discoverer can only find document level inboxes but not fragments), then I'm okay to let that go. Don't bother with HTTP HEAD and Link. Consequently, 1) makes it simpler for receivers (servers) to deal with this - no code for the headers need to be modified e.g., if an inbox (a "container") created, existing LDP implementations don't have to change their implementations on resources to announce their Link for the inbox. So, it is the resource data describing itself, not "out of band" data through the header. 2) senders/consumers make a single call on the resource and look for the inbox on resources that's of interest. Conclusion: f' headers, never liked them anyway!

Amy Guy
@rhiaro
Jul 02 2016 22:24
-1 on dropping headers. That means we are saying non-rdf resources can't have notifications about them, which is really none of our business. Allowing discovery via headers for document level in no way prevents #resources having inboxes
If you want to advertse for a #resource, put it in the body, simple
If you don't, you can use header
Sarven Capadisli
@csarven
Jul 02 2016 22:25
This is about RDF Sources! So, RDF Sources need not rely on the header. For NonRDFSource, Link is fine.
Amy Guy
@rhiaro
Jul 02 2016 22:26
As long as we say senders must check body if they don't find it in header, which we do, there's no conflict
We never said rdf sources 'need' to rely on header
Sarven Capadisli
@csarven
Jul 02 2016 22:27
Are you saying that if there is an inbox is in the Link, the body MUST NOT have inboxes?
Amy Guy
@rhiaro
Jul 02 2016 22:27
No
But there's no point
If you put a header it'll be discovered first
So just don't put a header
Sarven Capadisli
@csarven
Jul 02 2016 22:28
This doesn't work out of the box LDP
Amy Guy
@rhiaro
Jul 02 2016 22:28
Why would you put a header if you want them in the body?
How so?
Sarven Capadisli
@csarven
Jul 02 2016 22:29
Updating Link header is (typically?) done by the server
The sender will not be able to 'create' an inbox through a header.. but they can do that in the payload of the resource
Amy Guy
@rhiaro
Jul 02 2016 22:29
The server isn't going to randomly add an inbox header
What, when did we start talking about creating? Did I miss something?
Sarven Capadisli
@csarven
Jul 02 2016 22:30
We are not describing how inboxes will be created in the spec, but thi sis goign to be an issue if/wherever it is spec'ed
We are not per se.. i'm just trying to revisit this whole thing and not set limtations.
But we can put that aside.. if you prefer.. Are you suggesting that either the header Link is present or it is in the body?
Which is what I asked essentially: "Are you saying that if there is an inbox is in the Link, the body MUST NOT have inboxes?"
Amy Guy
@rhiaro
Jul 02 2016 22:32
So far we're saying you can advertise via header OR body. Header will be checked first, if not body will be checked. None of that in conflict with LDP
If you have links in the body, don't put it in header. What's the problem with that?
Sarven Capadisli
@csarven
Jul 02 2016 22:32
I mean.. it can, but the problem is that someone looking at the header, might just stop there and not look at the body, in which case, it will not be discovered
Amy Guy
@rhiaro
Jul 02 2016 22:33
So don't put a header
Why would you?
Sarven Capadisli
@csarven
Jul 02 2016 22:33
That's fine I guess.
We should be clear about this in the spec.
Amy Guy
@rhiaro
Jul 02 2016 22:33
If senders MUST check body, why would you need to use both?
Sarven Capadisli
@csarven
Jul 02 2016 22:34
"Senders and consumers must fetch the target resource URL (and follow redirects), or make a HEAD request, to check for an HTTP Link header with a rel value of http://www.w3.org/ns/ldp#inbox." needs to be reordered.
HEAD should come first and then the body.
the sentence following that is clear, but this is misleading a bit
Amy Guy
@rhiaro
Jul 02 2016 22:35
Oh I thought the order was already specified correctly
Sarven Capadisli
@csarven
Jul 02 2016 22:37
We could keep HEAD I guess..
And I can see that might be useful for some.
I just think that's limited.. described above.
and subject to desynchronising with the body.
Amy Guy
@rhiaro
Jul 02 2016 22:38
I don't understand the problem
Sarven Capadisli
@csarven
Jul 02 2016 22:38
(if they are both used)
Nevermind.. maybe discuss later.
Amy Guy
@rhiaro
Jul 02 2016 22:39
I don't know why you'd use both
Sarven Capadisli
@csarven
Jul 02 2016 22:39
I don't want to.
Do you mean... why would one would use both?
Amy Guy
@rhiaro
Jul 02 2016 22:39
I don't know why one would use both
Sarven Capadisli
@csarven
Jul 02 2016 22:39
Well, if the spec doesn't restrict that, they might. That's why.
If the spec is strict about ONLY one way, that's fine.
But.. I already explained why Link is limited.
Amy Guy
@rhiaro
Jul 02 2016 22:40
I thought it was already clear that if you discover in header, you stop looking. That should be enough
Sarven Capadisli
@csarven
Jul 02 2016 22:41
Going with Link is fine as long as the publisher acknowledges that limitation, and I think we should emphasise on that point in the spec (look, head/link is fine.. but ack that it can only be set on the doc or whatever)
Fine.
Amy Guy
@rhiaro
Jul 02 2016 22:41
Obviously link relates to doc
That's the most common case anyway
Sarven Capadisli
@csarven
Jul 02 2016 22:41
I supose
Amy Guy
@rhiaro
Jul 02 2016 22:42
Not a limitation
Sarven Capadisli
@csarven
Jul 02 2016 22:42
It is limited to cover only a category of URIs
Scope. Whatever you want to call it.
Amy Guy
@rhiaro
Jul 02 2016 22:43
And it's the easiest to understand case. The # thing is special case that SW people will understand but nobody else will even think of
Sarven Capadisli
@csarven
Jul 02 2016 22:43
That's fine.
Amy Guy
@rhiaro
Jul 02 2016 22:43
And # people aren't restricted in any way from using body
So should all be good
Sarven Capadisli
@csarven
Jul 02 2016 22:43
I'm looking at it broader.. discovery is not only through HTTP requests.. but could be queried for in an RDF store.
Alright.
So, now.. we just have to resolve the serialisation issue?
Amy Guy
@rhiaro
Jul 02 2016 22:44
We're not speccing discovery by query though are we?
Sarven Capadisli
@csarven
Jul 02 2016 22:44
  1. the resource body that announces its inboxes
  1. the inbox uri
  1. the notification uri
We are not.
Perhaps this is all fine. We established that everyone can be happy if the HEAD or GET can be utilised to find inboxes
Aside: I've tested LDN spec on Mac Firefox/Chrome, it didn't show the notification for some reason. Okay on Ubuntu. I'll have to look again when I get a chance. I recall it not working on your Ubuntu Mint Chrome either..
Amy Guy
@rhiaro
Jul 02 2016 22:48
I'm still uneasy about senders being required to parse rdf to discover but that's a different conversation.
There's no such thing as Ubuntu mint
:p Also I use kubuntu not mint
Sarven Capadisli
@csarven
Jul 02 2016 22:48
Whatever OS you were using on your laptop on Friday.
Sorry, I thoguht it was Mint.
Everyone can speak only JSON-LD, and that's fine, we can stop at that.. but that means discovery of inboxes in other serialisations (e.g., HTML+RDFa in dokieli) .. unless the server can send an JSON-LD serialisation of it.
Am I missing somehting?