These are chat archives for csarven/ldn

26th
Aug 2016
Melvin Carvalho
@melvincarvalho
Aug 26 2016 11:34
As a consumer of LD I dont want to have to check the link header in my code, but rather, obtain the inbox from the LD. Is it possible to make that part (checking link headers) optional?
use case: my media player container will have an inbox which will be discovered, I dont want to have to branch the code to handle link headers when all my discovery will be at the data layer, but id like to say im compliant with LDN if possible ...
basically via the inbox you can show which things you've viewed, give ratings, request new items etc.
or annotate a piece of a tv show so that with your friend watches it, your comment can be popped up
Melvin Carvalho
@melvincarvalho
Aug 26 2016 11:39
id suggest removing the link header part completely, is anyone using it?
Amy Guy
@rhiaro
Aug 26 2016 14:26
Yes
Link header is useful for site wide discovery, and if you don't have access to modify the data (feasible in enterprise kind of systems which host things like historical datasets for example)
The problem with making it optional is that then your code wouldn't be able to discover my inbox if I used link header to advertise it
which means we'd get two sets of implementations that couldn't interoperate
Your media player container can just use the data layer to advertise
it's only senders which need to be able to check link header and and data to discovery
resources choose one or the other
(because in some cases publish may only have access to modify either the headers or the data, but not both)
and you're of course welcome to check the data first and use link header as a fall back if you do not find an inbox there
I found it fairly straightforward to implement discovery that way
Melvin Carvalho
@melvincarvalho
Aug 26 2016 14:38
@rhiaro FYI: I dont think my implementations will support link header. Is there much demand for it?
it makes the code more complex for me
Its not fairly straightforward, imho, or at least, beyond my ability
Unless there's a clear benefit
Amy Guy
@rhiaro
Aug 26 2016 14:40
That just means that I wouldn't be albe to use your sender/consumer with my receiver
as my site advertises inbox over link header for the whole site
"just"
Melvin Carvalho
@melvincarvalho
Aug 26 2016 14:41
well why would you use the link header pattern?
this is probably a good thing
Amy Guy
@rhiaro
Aug 26 2016 14:41
So I don't have to edit the data for every blog post
Assume I can't touch my data.. which is the case for commercial datasets and such.
This lets developers who want to add notifications funcatility to some system they work on, but can't actually touch the data itself
We want to lower the barrier for publishers, basically
Melvin Carvalho
@melvincarvalho
Aug 26 2016 14:43
OK well just developer feedback, I would like to support inbox via follow your nose at the data layer. I dont have interest in link headers to do the same thing, and it potentially complicates things alot for me.
Amy Guy
@rhiaro
Aug 26 2016 14:43
To make it easier for anyone to have an inbox
Melvin Carvalho
@melvincarvalho
Aug 26 2016 14:43
If it gets big uptake ill consider supporting the whole spec, but that's years away, right?
Amy Guy
@rhiaro
Aug 26 2016 14:44
Noted
Melvin Carvalho
@melvincarvalho
Aug 26 2016 14:44
I really think you should put your inbox discovery with the blog post
Amy Guy
@rhiaro
Aug 26 2016 14:45
How would you solve that for someone with say a museum dataset, or a statistical dataset, who isn't allowed to touch the data?
Melvin Carvalho
@melvincarvalho
Aug 26 2016 14:45
void i guess
Amy Guy
@rhiaro
Aug 26 2016 14:45
I'm not sure i understand how that helps?
Melvin Carvalho
@melvincarvalho
Aug 26 2016 14:46
I thought void was a vocab for describing datasets. Could you not add a triple there to point to an inbox?
Amy Guy
@rhiaro
Aug 26 2016 14:46
Not if I can't publish any triples
Melvin Carvalho
@melvincarvalho
Aug 26 2016 14:46
If you cant publish triples why have an inbox?
Amy Guy
@rhiaro
Aug 26 2016 14:47
So I can receive notifications for my data
The inbox could be on another server
an LDP server somewhere
And every time someone links to or uses my data, I could receive a notification about that
But the data itself doesn't need to change for that to be possible
Melvin Carvalho
@melvincarvalho
Aug 26 2016 14:48
Honestly, I think discovery should happen at the data layer, via follow your nose, not the header layer.
It massively complicates implementations to be compliant
Amy Guy
@rhiaro
Aug 26 2016 14:49
I understand. But I also want to support it being possible for as many people to have an inbox as possible
Melvin Carvalho
@melvincarvalho
Aug 26 2016 14:49
so while i love LDN I cant list my implementation as compliant
Amy Guy
@rhiaro
Aug 26 2016 14:49
In my experience it's not that complicated, so I guess we'll have to wait for more people to implement to findout
Incidentally, all webmention implementations have managed it
Melvin Carvalho
@melvincarvalho
Aug 26 2016 14:49
Which library do you use?
to parse BOTH link headers and linked data, then disambiguate them
webmention implementations have not managed to do what LDN proposes
this is a really hard task
Amy Guy
@rhiaro
Aug 26 2016 14:51
Webmention requires link header to be checked first, then html to be parsed
LDN at least lets you pick the order
I use EasyRdf for linked data and two small php functions I found on github for parsing link headers
Melvin Carvalho
@melvincarvalho
Aug 26 2016 14:51
that's not the point
you have to do both
then you have to have a controller decide what to do with both
Amy Guy
@rhiaro
Aug 26 2016 14:52
Right. And the webmention implementations - for which discovery is basically the same - mmanage to do both
I can't comment on this for JS though I'm afraid
Melvin Carvalho
@melvincarvalho
Aug 26 2016 14:52
it's not the same
Amy Guy
@rhiaro
Aug 26 2016 14:52
But I'll look into a way to do it if that helps
Melvin Carvalho
@melvincarvalho
Aug 26 2016 14:52
because LD is not html
Amy Guy
@rhiaro
Aug 26 2016 14:52
apart from the html part
you just replace that with the rdf discovery instead
the link header part is the same
Melvin Carvalho
@melvincarvalho
Aug 26 2016 14:52
LD is hugely different from what webmention parses
it's a full triple/quad model
Amy Guy
@rhiaro
Aug 26 2016 14:53
The link header is the same
the value of a rel
Would this help for example? https://github.com/thlorenz/parse-link-header
I say first parse the source and look for ldp:inbox. If not found, parse the link headers and use the inbox from there instead
Melvin Carvalho
@melvincarvalho
Aug 26 2016 14:55
it hugely complicates the data footprint
Amy Guy
@rhiaro
Aug 26 2016 14:55
I don't know what that means
Melvin Carvalho
@melvincarvalho
Aug 26 2016 14:55
discovery in LD is done via follow your nose at the data level, link headers are for something else
Amy Guy
@rhiaro
Aug 26 2016 14:55
Whether/how you store the inbox alongside the rest of the parsed source data is up to you
I'm more interested in allowing as many publishers as possible to be able to have inboxes than maintaining the purity of separation between data and link headers at the present time
Melvin Carvalho
@melvincarvalho
Aug 26 2016 14:57
same could be said of other triples, that's just not how linked data works, also you might not want inbox at a document level, but at a fragid level
Amy Guy
@rhiaro
Aug 26 2016 14:57
You can do that of course
as dokieli does
you can't use the link header to publish that
but that's fine, becausae publishers choose one way
and can use it in data, at fragid
and senders, who are required to check the source as well, will find that no problem
It also lets us add inboxes for things like images..
Melvin Carvalho
@melvincarvalho
Aug 26 2016 14:58
the whole point of linked data is that the data links to other data, and via those triples you can great a graph
Amy Guy
@rhiaro
Aug 26 2016 14:59
and we're not preventing that
Melvin Carvalho
@melvincarvalho
Aug 26 2016 14:59
i think its a weak argument to say that data publishers cant edit data, so we'll find some other hack
anyway gtg
Amy Guy
@rhiaro
Aug 26 2016 14:59
the focus here is on being able to all LD to be used for notfications everywhere, not just RDF resources
So things that aren't LD can start using LD for other cool functionality
ie we want LDN to be usable all over the web, not just in pure RDF systems
Amy Guy
@rhiaro
Aug 26 2016 15:06
Oh yeah, we even got an email from a heritage organisation interested in LDN who specifically said they want to be able to advertise with link headers
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:11
oh thanks
im afraid its too much complexity
my implementations already have a lot of moving parts
mixing the header and data layer then disambiguating them is a huge barrier
ill have to remove my implementation from the list
but ill work on the basis of an LDN lite
that is based on linked data
because my current implementation just follows from the webid to the inbox
and my future will follow from the media gallery to its inbox
Amy Guy
@rhiaro
Aug 26 2016 15:16
that's fine, thanks for your support thus far
hopefully if we get more potential receivers advertising their inboxes this way it'll be worthwhile to add for you
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:17
right
but i hope that doesnt happen
because it's not a clean separation of document and data, and will just explode complexity
of code
Amy Guy
@rhiaro
Aug 26 2016 15:19
not necessarily everyone's experience, but I acknowledge that is how it would be for you
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:19
really LDN should be two specs
one for linked data
and one for others
Bart van Leeuwen
@semanticfire
Aug 26 2016 15:20
and you want less complexity ?
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:20
ld is already complex
Bart van Leeuwen
@semanticfire
Aug 26 2016 15:20
I do not agree with that :)
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:21
i should maybe rephrase, implementations working with LD when solving practical use cases get complex very quickly
a spec that says, 'on top of everything else, you now have to persist every header ever seen, store it, compare it with the content, and then apply logic as to what is definitive just is a huge undertaking'
Bart van Leeuwen
@semanticfire
Aug 26 2016 15:22
I think thats a problem of over engineering
Amy Guy
@rhiaro
Aug 26 2016 15:22
it really doesn't say that
you just have to get the link headers, and pay attention to one with rel="ldp:inbox"
you can ignore everything else
I run my whole site with LD and it's been way simpler than anything I had before
Bart van Leeuwen
@semanticfire
Aug 26 2016 15:23
I think e-tags serve a pretty similar purpose
and are widely supported and implemented
Amy Guy
@rhiaro
Aug 26 2016 15:24
and LDP uses type headers, too
Melvin, just to be clear - if you do find an inbox in the data source, you can stop. You don't have to go on to check the header as well.
you only check the header if you don't find an inbox elsewhere
Bart van Leeuwen
@semanticfire
Aug 26 2016 15:26
I publish realtime linked data about fire incidents, I don't wanna bloat that with another triple describing where you cansubscribe to it
Amy Guy
@rhiaro
Aug 26 2016 15:26
So "compare with the content ... as to what is definitive" isn't necessary
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:26
thanks, but you have to code both cases either way, to be compliant
Amy Guy
@rhiaro
Aug 26 2016 15:27
Indeed, but I think you're overestimating the complexity
you don't have to compare them or anything
just pull out the value
and POST/GET to it as normal
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:29
and what when there are two values, on in the document one in the header?
the code has to handle this
Amy Guy
@rhiaro
Aug 26 2016 15:29
If someone publishes two, they should know that it's pot luck which ones senders/consumers land on
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:29
quite simply one will be correct and the other incorrect
Amy Guy
@rhiaro
Aug 26 2016 15:29
you as a sender/consumer don't need to worry about that. Use whichever you get first
Publishers SHOULD NOT use two (I forget if we say that, maybe we should) and if they do, it's their problem
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:30
its also the problem of the consumer
Amy Guy
@rhiaro
Aug 26 2016 15:30
or, use whatever logic you want to decide which to use
there's no good reason for a publisher to use both and them to be different
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:30
its not that simple, you write a financial app and get it wrong, and money gets sent to the wrong place
Amy Guy
@rhiaro
Aug 26 2016 15:30
so if they do, it's a bug on the publishers end
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:31
bugs happen in markup all the time
Amy Guy
@rhiaro
Aug 26 2016 15:31
I mean, LDN can't help you if you badly code a financial app regardless
Bugs in implementations are not the same as bugs in specs
The spec has this covered
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:31
it can help you by avoiding this class of bugs all together
Amy Guy
@rhiaro
Aug 26 2016 15:31
It does, publishers SHOULD (maybe we upgrade to MUST?) NOT publish inboxes in both ways
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:31
by not giving the implementor chance to put something on one of two places
Amy Guy
@rhiaro
Aug 26 2016 15:32
They MUST use the link header OR the body
and senders and consumers MUST check both, because it could be in either. But it WILL NOT be in both.
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:33
well i hope that happens, but i can see some publishers making mistakes
Amy Guy
@rhiaro
Aug 26 2016 15:33
If this is something we can clarify in the spec I'm more than happy to do that
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:33
and the consumer has to handle both cases
sorry
Amy Guy
@rhiaro
Aug 26 2016 15:33
There are many things implementations can make mistakes on
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:33
perhaps i shoudlnt say consumer
that's a confusing word
the sender i mean
which is the code i wrote
Amy Guy
@rhiaro
Aug 26 2016 15:34
senders and consumers both do discovery this way, so that's fine
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:34
oh right
Amy Guy
@rhiaro
Aug 26 2016 15:34
and again, you only need code that tries one, and tries the second only if the first fails
it doesn't need to try both then make a decision
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:34
haha, i said the wrong thing and got lucky! :D
Amy Guy
@rhiaro
Aug 26 2016 15:34
(you can if you want, but you don't need to)
so hopefully that reduces some of the complexity you saw before
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:34
what im saying is that you have to write both branches of code
if you want to comply
that's a really high barrier for client side apps
Amy Guy
@rhiaro
Aug 26 2016 15:35
Is it?
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:35
yes
Amy Guy
@rhiaro
Aug 26 2016 15:35
The parts you said were complex earlier aren't actually necessary
so parsing link headers is really all you need, which there's lots of code out there for
and as reluctant as I am to use webmention as an example here, all webmention sending clients have done this, suggesting it's maybe not such a high bar
Bart van Leeuwen
@semanticfire
Aug 26 2016 15:36
I'd like to see a very complex code sample on this
because I don't see the issue with checking either of the 2
Amy Guy
@rhiaro
Aug 26 2016 15:36
and if we remove the link header we lose potentially 50% of people who could otherwise publish inboxes, but now can't (like Bart's example)
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:37
@semanticfire do you require the link header pattern?
Amy Guy
@rhiaro
Aug 26 2016 15:37
I'm happy with this marginally higher bar for senders if it drastically lowers the bar for publishers.
You can see here how I did the check for both in less than 50 lines of (very spaced out) PHP: https://github.com/linkeddata/errol/blob/master/index.php
(errol is a sender)
Bart van Leeuwen
@semanticfire
Aug 26 2016 15:39
I'm not gone generate a triple for a inbox on every incident no
Amy Guy
@rhiaro
Aug 26 2016 15:39
$inbox = inbox_from_header($url);
  if(empty($inbox)){
    // parse source and look for ldp:inbox there instead
  }
The other advantage of this is, for a HUGE rdf source, I don't have to parse it all if I don't need to
that's why I look at the header first in fact
if there's a big statistical dataset, for example, with an inbox and all I care about is the inbox not the rest of the data, I definitely don't want to parse it if I don't have to
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:40
@rhiaro I've written around 10,000 lines of client side linked data code in the last year. You dont have to take my word that is is very complex stuff with a high bar, but I do have some experience here.
Bart van Leeuwen
@semanticfire
Aug 26 2016 15:41
stepping out for dinner, don't give met 200 misses messages again :P
Melvin Carvalho
@melvincarvalho
Aug 26 2016 15:41
@semanticfire cant you have a parent container for incidents with an inbox?
enjoy!
anyway good luck with the spec, ill remove my implementation from the list.
lots of things i love about LDN still
that part is just not aligned with my work, and id encourage you, and other publishers, to consider putting the discovery triples with the rest of the data
just some feedback
Amy Guy
@rhiaro
Aug 26 2016 15:51
Just to confirm, the spec does indeed already say "A resource MUST advertise only one Inbox."
Melvin Carvalho
@melvincarvalho
Aug 26 2016 16:00
@rhiaro ack, I got that.
but the code has to do both, and also deal with the edge case where both fields are full
Amy Guy
@rhiaro
Aug 26 2016 16:04
for me, if I find one in the first check, I don't bother with the second check, so I never have to deal with two
but even so, "deal with" is fine to just be "pick one"
Melvin Carvalho
@melvincarvalho
Aug 26 2016 16:04
mashing link header discovery semantics into the data knowledge base alone is a large burden
Amy Guy
@rhiaro
Aug 26 2016 16:04
If you want to make it more complicated you can, but there's no need to
not sure what you mean by "mashing link header discovery semantics into the data knowledge base"
Melvin Carvalho
@melvincarvalho
Aug 26 2016 16:05
typically follow your nose discovery in LD is done at the data / content level
FYN via link headers isnt just hard, it's a sea change
Amy Guy
@rhiaro
Aug 26 2016 16:06
Indeed. While you're doing that discovery though, you're looking for a specific property. So if it's just a case of: if you don't find it, call another function that checks the link header on that resource too
For me, I find the necessity to parse a whole document to be more of a burden
If you're doing that anyway it's not, but if you're just a sender and only need to find the inbox, it's overkill
Melvin Carvalho
@melvincarvalho
Aug 26 2016 16:07
understood
different perspectives i guess
Amy Guy
@rhiaro
Aug 26 2016 16:07
So this is the compromise, which I think is reasonable
Melvin Carvalho
@melvincarvalho
Aug 26 2016 16:07
just giving mine
Amy Guy
@rhiaro
Aug 26 2016 16:07
and enables more people to have inboxes
which is ultimately what's important
Melvin Carvalho
@melvincarvalho
Aug 26 2016 16:08
i really wish LDN was split into these two pieces then
one for those working with LD
and one for everyone else
i guess it's not a huge issue, more bureaucratic then anything else
Amy Guy
@rhiaro
Aug 26 2016 16:09
It's not that you can't or wouldn't also use link headers with RDF resources though.. so I don't know how that would help. Certainly wouldn't help with interop.
Maybe we have a conformance class which is something like "only works with pure RDF stuff" but again, not good for interop in general
and the LD part of LDN is not about the resources advertising inboxes, it's about the fact that the notifications are LD
so it's just getting more LD out there in general... regardless of what people start with. Which I thought you'd see as positive thing
Melvin Carvalho
@melvincarvalho
Aug 26 2016 16:11
i dont really have an opinion on that
i came into this technology to get things done
because other approaches lead me to hit walls
if others can get things done without hitting those walls that's something good
i dont like LD just for the sake of it, it's that content in documents in triple form allows you to model every use case you will pretty much ever need
Amy Guy
@rhiaro
Aug 26 2016 16:13
Indeed. Unfortunately everybody is not quite there yet, with modelling everything as RDF
But I don't think this should exclude them from having inboxes :)
Melvin Carvalho
@melvincarvalho
Aug 26 2016 16:14
agreed
but that's why i would have liked it to be two specs
then i could list my conformance to one
Amy Guy
@rhiaro
Aug 26 2016 16:15
You can list as conformant with the caveat of no link header support for now, and we can think about conformance classes sometime perhaps. But two separate specs is overkill... LDN is tiny as is
Melvin Carvalho
@melvincarvalho
Aug 26 2016 16:16
sounds good!
right now im going to have a structure
/container/
/container/notify.ttl
/container/inbox/
the container will be a dymanic entity with a changing media library
when it changes notify.ttl will send out a pub / sub
then the clients can all pull in the new items, while keeping a cache of what they have already
when they are through consuming content
they can add annotations, ratings, request for content etc. to the inbox
Amy Guy
@rhiaro
Aug 26 2016 16:19
nice
Melvin Carvalho
@melvincarvalho
Aug 26 2016 16:20
maybe i can get rid of notify.ttl if containers do pings, but not sure that works
then it will just be
 /container/
 /container/inbox/
and inbox can be found from container via an LDN like discovery
so you just point your browser / client at the container
and you start to see a streaming library of media
Amy Guy
@rhiaro
Aug 26 2016 16:21
Looking forward to seeing this
Melvin Carvalho
@melvincarvalho
Aug 26 2016 16:22
well it's pretty much all working as proof of concept :)
only major problem is that notifications arent working on databox
so i have to work on my own server
its working fine on localhost
actually im in my co working space now, and streaming media from my solid desktop across the city :)
hopefully gives you an idea: https://solid-live.github.io/slideshow/
Amy Guy
@rhiaro
Aug 26 2016 16:26
shiny
Melvin Carvalho
@melvincarvalho
Aug 26 2016 16:26
:)
Amy Guy
@rhiaro
Aug 26 2016 16:26
That slideshow app is super nice
Melvin Carvalho
@melvincarvalho
Aug 26 2016 16:27
try this
shiny
just made it :)
Amy Guy
@rhiaro
Aug 26 2016 16:28
+1 :D
which saves to your solid space
(ctrl L = login. ctrl S = save) ... type stuff into box to search youtube
Melvin Carvalho
@melvincarvalho
Aug 26 2016 16:43
it's all hooked up to a payments system too
so when i do some work, i 'earn' enough credits to watch some tv
Melvin Carvalho
@melvincarvalho
Aug 26 2016 16:53
btw linked data != rdf
any system that creates a graph or data based on URIs ie the GGG can be thought of as linked data
rdf is just the best implementation we have so far
any other system passing the test of independent invention would also be linked data and be interoperable by definition
the problem comes when you mix that data layer with the transport layer
a good robust data model should be independent of the transport, this isnt always possible, but it's a good architectural goal
and also make good candidates for standardization imho
Melvin Carvalho
@melvincarvalho
Aug 26 2016 16:59
while you can get a good sugar rush by mixing the transport layer (eg http) and the data, as ive probably done more times that id like to admit, it tends to come back and bite you when you try to scale
Melvin Carvalho
@melvincarvalho
Aug 26 2016 18:48
I raised an issue to capture our discussion.
Melvin Carvalho
@melvincarvalho
Aug 26 2016 18:54
im not sold on the site wide headers for those that dont wish to change content argument
but one use case I can see is with a 4xx to return an inbox header
which might be a hint on to how to get access etc.
because in that case you cant really send back structured data easily
so some help as to what to do is useful
Amy Guy
@rhiaro
Aug 26 2016 18:57
Thanks for the issue
I'll try to recapture our discussion from today there
Melvin Carvalho
@melvincarvalho
Aug 26 2016 21:14
Thanks @rhiaro
basically im arguing for modularity
one thing im a little bit more interested in is LDPC notifications
in solid when a resource changes you can get a websocket update
but im not sure LDPC works so well
if im watching a container how can I know it changes? that would be a great problem to solve
eg someone puts something new in their or takes something out, id love my client to automatically refresh its view
id like to be able to trigger a notification too, lets say if i add something on my file system and clients are watching that folder
Melvin Carvalho
@melvincarvalho
Aug 26 2016 21:27
i guess thats probably out of scope and something for a new spec
Amy Guy
@rhiaro
Aug 26 2016 21:30
yeah, we're referring to that as a subscription mechanism, and have included a new section on it (saying that it's out of scope): https://linkedresearch.org/ldn/#subscribing-to-notifications
We figured there are many subscription mechanisms, and it's too early for to specifically pick one for use with LDN - all could work
Melvin Carvalho
@melvincarvalho
Aug 26 2016 21:38
the thing is that you need all 3 for a good working system
  • read
  • write
  • notifications
developers will be looking for a reference implementation with all 3
we need notifications for LDPC / LDPR
Melvin Carvalho
@melvincarvalho
Aug 26 2016 21:43
oh i think i found a bug
Subscribing to a container can also be really useful, since all CRUD operations (POST, PUT, PATCH, DELETE) performed on resources of that container will trigger a notification for the container URI. This makes synchronization between multiple apps really easy.
in solid
im not sure it does that
that's my problem right now
so instead of
/container
/container/notify
/container/inbox/
that wont work
because the inbox will trigger a notification
i can remove the notify completely and just watch the container
and have
/container
    /content
    /inbox
then you need a robot watching the inbox and managing the content
robot or human! :)
Melvin Carvalho
@melvincarvalho
Aug 26 2016 21:48
it seems that's going to be the general design pattern ... where do you put an inbox? either in a well known place for bulk updates, you cant really put it below the content, and cant really put it above, so it will normally be a sibling in a self contained system
it's almost worth adding a well known pattern for this ...
actually finding inboxes for containers isnt easy
possibly a hack too far