These are chat archives for csarven/ldn

21st
Sep 2016
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 16:25
@csarven double checked, node-solid-server complies with https://linkedresearch.org/ldn/#receiving
(with the small caveat of - it returns Accept-Post header on an OPTIONS request, but not on HEAD)
Amy Guy
@rhiaro
Sep 21 2016 16:26
@dmitrizagidulin++
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 16:32
it also complies with Discovery (though the second method only, via GET), and Sending
Amy Guy
@rhiaro
Sep 21 2016 16:34
Cool!!
Didn't know for sure Sending was working
That's excellent
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 16:34
yep, double-checked.
Amy Guy
@rhiaro
Sep 21 2016 16:34
If it's only doing discovery with GET, it has to commit to only every targeting fragids basically
until such a time as it wishes to consider documents
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 16:35
explain?
(er, wait, Sending is working in the sense of, if I send a notification to node-solid-server, it works fine. But I suppose that's Receiving. and Sending is more of a client lib feature)
Amy Guy
@rhiaro
Sep 21 2016 16:37
oh right I thought you were talking about the client
yeah
discovery is also part of sending, not part of receiving
did you mean 'advertising an inbox' when you said discovery?
in which case, just in body is fine
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 16:37
yeah, advertising
as far as the inbox link header.. we still, fundamentally, don't have a good mechanism for users or apps being able to add custom headers like that
or for the server to add them automatically
Amy Guy
@rhiaro
Sep 21 2016 16:38
yeah that's fine
I thought you meant from the client
Nae problem at all
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 16:39
k
Amy Guy
@rhiaro
Sep 21 2016 16:39
So... you can have sending in the client by tomorrow, yeah :p
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 16:40
my only further thoughts, in that regard (as far as the link header), is -- we could add a feature where 1) if a container's .meta contains an inbox triple, the server adds that to the header. and 2) if a binary file's (non-rdf resource's) .meta contains an inbox triple, it adds it to the header
heh, maybe
I mean, technically, you could send notifications using hte plain solid-client, right? though I suppose helper functions couldn't hurt
Amy Guy
@rhiaro
Sep 21 2016 16:41
right, a helper would be an implementation
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 16:41
nods working on it.
Sarven Capadisli
@csarven
Sep 21 2016 16:48
(with the small caveat of - it returns Accept-Post header on an OPTIONS request, but not on HEAD) -- This is OKAY! @dmitrizagidulin
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 16:48
excellent
so.. how would you guys feel about a small amendment to the discovery algorithm?
csarven @csarven raises his eyebrow as high as possible.
Sarven Capadisli
@csarven
Sep 21 2016 16:48
Go on..
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 16:49
a third step, being -- if the rel="inbox" header is not present, but a rel="meta" header IS present,
try and fetch the contents of .meta, and search /it/ for an inbox predicate
(most useful for things like non-rdf resources)
Melvin Carvalho
@melvincarvalho
Sep 21 2016 16:49
nice idea
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 16:50
(but also could get around the fact that we don't have a good mechanism for the inbox header for rdf resources, in solid)
Sarven Capadisli
@csarven
Sep 21 2016 16:50
why not do that in the body of any resource instead of hoping through .meta?
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 16:51
for one, in case the resource is a non-rdf resource. like a .jpeg
Sarven Capadisli
@csarven
Sep 21 2016 16:53
What's the actual resource that's being described in that case?
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 16:53
what do you mean
(I mean, granted, that's an exotic use case.)
Sarven Capadisli
@csarven
Sep 21 2016 16:54
text/turtle returning triples in http://example.org/foo.png ?
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 16:54
no, foo.png is just a png. but it also has a rel="meta" link header that /does/ have triples
(when dereferenced)
Sarven Capadisli
@csarven
Sep 21 2016 16:55
Are the those triples in text/turtle a "representation" of http://example.org/foo.png?
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 16:55
more like additional metadata
(including, hopefully soon, things like who authored it, etc.)
Sarven Capadisli
@csarven
Sep 21 2016 16:57
I think it is a bit exotic. I'm not fundamentally opposed to it. The primary issue I have with this is that, it is not a publishing pattern that's "common" in the LD. People publish like this:
http://csarven.ca/#i has avatar x.
x was made by http://csarven.ca/#i
(e.g., foaf:maker)
And they are normally found in the same document for this specific case.
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 16:59
sure. that's the current state of affairs. but it's also fairly limited.
because if you start with x, how are you going to discover that document with those triples?
if not through something like rel="meta"
Melvin Carvalho
@melvincarvalho
Sep 21 2016 16:59
@dmitrizagidulin can you read .meta if you dont have read access to a file?
Sarven Capadisli
@csarven
Sep 21 2016 16:59
If that's the case, why would ldp:inbox in the header not be sufficient but somehow rel=meta is?
They still point to a resource
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 17:00
@melvincarvalho you know that's an interesting question. currently, the permissions for .meta (in solid) are completely separate from the file's permissions
Melvin Carvalho
@melvincarvalho
Sep 21 2016 17:00
ok
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 17:00
@csarven because we don't /have/ a mechanism for adding a ldp:inbox to the header :)
Melvin Carvalho
@melvincarvalho
Sep 21 2016 17:00
because you can ALWAYS see the headers
even if you get a 4xx
so .meta would have to operate the same way to be equivalent
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 17:02
so part of the issue here is that in solid, the .meta mechanism has only two uses, really. (most commonly). one is - to add triples to a container. (but those triples are actually returned by just getting the container itself.) and two - to add RDF triples to a non-rdf resource
Sarven Capadisli
@csarven
Sep 21 2016 17:02
You could see but not necessarily should. If 401/403, for instance, there is absolutely no reason why an particular/specific information like that should be visible to begin with.
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 17:02
like, if you PATCH a solid container, and insert some triples, those will actually be inserted into that container's .meta
sure. different issue.
@csarven so what I'm hearing is, you're not opposed to the idea, but given that it applies only to a couple of exotic use cases, it might not be worth messing with at the current time. yeah?
(the idea being - adding a 3rd step to the discovery algo)
Sarven Capadisli
@csarven
Sep 21 2016 17:24
Not opposed to it. Need to think more about it. It does however add extra complexity for discovery. In this particular scenario, I'm in favour of simplicity and actual usage out there. People have been using things like foaf:maker inside another document that could be discovered/FYNed. So, no particular reason why ldp:inbox as a property of a foaf:Image instance can't be done as well.
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 17:27
unrelated - the lack of a specified format for the notification payload makes it somewhat difficult for implementing on the client side (both for sending and receiving)
Sarven Capadisli
@csarven
Sep 21 2016 17:27
The other thing to note here is it a common practice to resolve a non-RDF resource and then hope/look for RDF somewhere down the chain?
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 17:27
as in, I can probably make a notification display app that can display /my/ notifications, but no guarantee that it'll understand anybody else's
Sarven Capadisli
@csarven
Sep 21 2016 17:28
That's because you'll be designing that based on the vocabs that you want to implement
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 17:29
sure. but the end result is - the notifications are very much segregated / silo'd.
Sarven Capadisli
@csarven
Sep 21 2016 17:29
You can use any vocab.. ActivityStreams vocab is one of those that's fit for this purpose.
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 17:29
it's like if the SMTP protocol didn't specify a format for the email headers.
Sarven Capadisli
@csarven
Sep 21 2016 17:29
How so?
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 17:29
it just said "you can send and receive /something/, good luck on figuring out what it actually is"
interop between independent implementations isn't possible, though. given the current state of the spec
Sarven Capadisli
@csarven
Sep 21 2016 17:30
The "specification" *can be imposed by the owner of the inbox resource using ldp:constrainedBy and a shapes constraint (like SHACL)
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 17:30
what does that even mean tho?
I can implement a solid client that sends some sort of notifications. but nobody else's inbox app will be able to display them.. (unless it just dumps the raw rdf)
similarly, I can create a Solid Inbox app that displays stuff... but only stuff that my own implementation sends
(or else a raw rdf dump)
Sarven Capadisli
@csarven
Sep 21 2016 17:33
solid/node-solid-server#444
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 17:34
I'm looking at it.. i don't understand what it means
Sarven Capadisli
@csarven
Sep 21 2016 17:34
This problem has nothing to do with LDN but in fact processing or displaying of arbitrary RDF without prior knowledge. There is a long list of research and tooling on this .. ranging from specific to general purpose RDF consumption.
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 17:35
I can't parse the paragraph in the LDP spec that it links to. " LDP servers MUST publish any constraints on LDP clients’ ability to create or update LDPRs, by adding a Link header with an appropriate context URI, a link relation of http://www.w3.org/ns/ldp#constrainedBy, and a target URI identifying a set of constraints [RFC5988]"
what set of constraints, though? RFC 5988 is just the web linking rfc
not any kind of explanation of what constraints it means
Sarven Capadisli
@csarven
Sep 21 2016 17:36
I agree that this is a challenge, but it is not unique to LDN. ldp:constrainedBy and with something like SHACL could get you closer to that. If a receiver doesn't propose a constraint on the data, that's their call. If they want something with a particular shape, then they have the mechanism to that. And, that's what you essentially want as either a consumer or receiver.
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 17:37
my question is very practical, though. how are you going to demonstrate interop between independent implementations?
Sarven Capadisli
@csarven
Sep 21 2016 17:37
e.g., if you want an inbox with notifications only about 'new followers', then describe it so that the payload must contain such and such.
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 17:38
the #constraints link is helpful. (altho the bib link to web annotations is broken)
Sarven Capadisli
@csarven
Sep 21 2016 17:38
It is not a one size fits all interop.
Fixed the link, thanks.
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 17:41
np
Sarven Capadisli
@csarven
Sep 21 2016 17:41
So, ldp:constrainedBy says that it can be human or machine readable.
Web Annotations uses the spec as the constraints that should be followed
SHACL would be the machine-readable approach.
You could use something else of course.
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 17:42
are you aware of any SHACL libraries in javascript?
Sarven Capadisli
@csarven
Sep 21 2016 17:42
I will implement/experiment SHACL sometime soon.
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 17:43
(I couldn't find any when I last looked at it, at the beginning of the year)
Sarven Capadisli
@csarven
Sep 21 2016 17:43
i think ShEx had something.. not sure. someone mentioned it yesterday at TPAC.
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 17:43
same with shex. nothin' in javascript land
Dmitri Zagidulin
@dmitrizagidulin
Sep 21 2016 17:50
at least that I could find.