Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 26 17:52
  • Sep 23 14:42
    nmerm starred w3c/ldn
  • Jun 14 09:42
    KMax closed #66
  • Jun 14 09:42
    KMax commented #66
  • Jun 14 09:29
    csarven commented #66
  • Jun 14 09:25
    KMax commented #66
  • Jun 14 09:19
    csarven commented #66
  • Jun 14 09:16
    KMax starred w3c/ldn
  • Jun 14 09:16
    KMax opened #66
  • May 28 09:46
    ertugerata starred w3c/ldn
  • May 14 21:37
    QuantumCloudDatabase starred w3c/ldn
  • Apr 17 19:39
    salifm starred w3c/ldn
  • Mar 05 16:44

    plehegar on master

    Boilerplate files (compare)

  • Mar 05 14:51
    AntoniaWild starred w3c/ldn
  • Feb 03 17:03
  • Dec 04 2018 11:49

    csarven on master

    Remove unused CSS/JS in ED Change spacing from 4 to 2 (compare)

  • Oct 05 2018 07:02
    taurenshaman starred w3c/ldn
  • May 22 2018 03:15
    BlackGlory starred w3c/ldn
  • May 11 2018 19:16
    js-choi starred w3c/ldn
Sarven Capadisli
@csarven
The 'receiver' is acting as the storage for the notifications. The sender is notifying the receiver. We've just happened to separate the actor 'consumer' as its own. It is not necessarily the final recipient of the notification.
Amy Guy
@rhiaro
It's not out of scope for the WG - in fact, the SocialWG is getting PubSubHubbub as an editor's draft soon, and ActivityPub (another WG spec) contains it's own subscription mechanism - and in part because of these, it's out of scope for the LDN spec in particular. There are lots of subscription mechanisms. We'd gladly accept help on assembling a list of the most applicable so we can point to them from LDN. But I don't know that we have the expertise to just pick one and say MUST or SHOULD do this. So far several people have suggeseted a subscription mechanism is useful, and everyone has offhandedly suggested something completely different..
Sarven Capadisli
@csarven
Aside: I would prefer that we don't end up writing tests for the pub/sub section. Not a requirement for LDN receiver/consumer
Bart van Leeuwen
@semanticfire
is a WG Note a option, "this is how one could do it "
nice discussion topic over beer next week :P
Amy Guy
@rhiaro
We can certainly have a 'how one could do it' in the LDN spec
If there are several suitable possiblities we can list them
Bart van Leeuwen
@semanticfire
I even would see a place for LDN over JMS e.g.
Bart van Leeuwen
@semanticfire
there is no standard way to communicate updates of linked data in enterprise environments
Melvin Carvalho
@melvincarvalho
SPARQL 1.1? (Update) ?
Bart van Leeuwen
@semanticfire
that is equal to stating that in enterprise environments all updates are communcated in SQL ??
Melvin Carvalho
@melvincarvalho
Can be sent via PATCH + mime type application/sparql-update I think ...
Bart van Leeuwen
@semanticfire
the affordances are clearer with LDN, you announce a update and you get confirmation that the update is recieved, with sparql update if you get a okay, the sender migh assume that the data is inserted
Melvin Carvalho
@melvincarvalho
true
Sarven Capadisli
@csarven
Sarven Capadisli
@csarven
@semanticfire You can try to come for open lunch (at 12:00) on Tuesday at MIT/W3C office and also meet some folks there. @rhiaro and I have a SWWG call partly on LDN (I think at 13:00), but afterwards we can continue. Tuesday evening is difficult for me to meet.
Bart van Leeuwen
@semanticfire
@csarven I'll land around 17:00 :smile: so that's not gonna work, anybody else?
Amy Guy
@rhiaro
I'm around any time
Bart van Leeuwen
@semanticfire
How about dinner downtown?
Sarven Capadisli
@csarven
Sorry, unfortunately I can't make. I hope the discussion generates issues, improvements on spec, or new implementations ;)
Sarven Capadisli
@csarven
I think the w3id.org/ldn ns has some nice properties: 1) relatively open control (individuals vs going through an organisation body), 2) extensibility - terms can be added/clarified down the line about LDN - right now we only use the inbox property but other LDN-like stuff can go there, 3) very low admin involvement
I still have some preference for the LDP ns because it feels like the right thing to do.
Bart van Leeuwen
@semanticfire
We had a good discussion about LDN and workgroup issues
I still some potential for LDN as payload describer even in enterprise environment
Sarven Capadisli
@csarven
Cool. Looking forward.
Bart van Leeuwen
@semanticfire
Could a LDN Inbox have its inbox elements inlined ?
Melvin Carvalho
@melvincarvalho
I think so. Could you elaborate on what you mean? You mean the discovery predicate could be put in its own document?
Bart van Leeuwen
@semanticfire
no if you request the inbox, which in the document uses LDP container to point to its 'messages' could the messages be inlined ( as with LDP Container )
Melvin Carvalho
@melvincarvalho
we implement this using "globbing" so when I GET Container/* it gives me all the messages. Perhaps not the most elegant solution but very useful! :) This is something that could perhaps benefit from more standardization.
Bart van Leeuwen
@semanticfire
I'm looking at creating a 'frontend' on top of a JMS Queue with LDN spec
so a RESC interface to read out JMS Queues/Topic
Bart van Leeuwen
@semanticfire
REST Interface
Amy Guy
@rhiaro
@semanticfire You can totally return the inbox elements inlined. So long as you return the minimum ldp:contains relation, anything extra you want to include there is up to the implementation
I think I'm probably going to do that with my inbox
Melvin Carvalho
@melvincarvalho
hmmm
Amy Guy
@rhiaro
I'm 99% sure this is okay from the LDP perspective, too
Melvin Carvalho
@melvincarvalho
how will that work in the file system?
Dmitri Zagidulin
@dmitrizagidulin
the issue is not that it's ok or not from the LDP perspective. It's that it's an unspecified behavior, one way or another
I think one of the to-do items for the LDP Next group is to standardize inlining
so meanwhile, I think it's totally legit
Bart van Leeuwen
@semanticfire
If a inbox item is gone, a standard '410' would be within the spec of LDP I guess, since JMS Queue/Topic use a destructive read a URI will definitly not persist
Dmitri Zagidulin
@dmitrizagidulin
what's the question? 410 vs a 404?
Bart van Leeuwen
@semanticfire
410 -> gone
Amy Guy
@rhiaro
410 is fine, we don't really specify things like that for individual notfications
(anyone happen to know if LDP uses 410 for resources that are deleted?)
Dmitri Zagidulin
@dmitrizagidulin
i think it's a soft recommendation
it's hard to enforce something like that, even these days.
Melvin Carvalho
@melvincarvalho
6.2.3 LDP servers remove the resource identified by the Request-URI in response to a successful HTTP DELETE request. After such a request, a subsequent HTTP GET on the same Request-URI usually results in a 404 (Not found) or 410 (Gone) status code, although HTTP allows others.
Amy Guy
@rhiaro
@melvincarvalho How it works for fs is an implementation detail. Just as you presumably regenerate the ldp:contains triples whenever something new is created, you can add the resource triples to that file as well
Melvin Carvalho
@melvincarvalho
i think it's a rather big implementation detail