Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 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
  • Mar 21 2018 14:59
    luismendes070 starred w3c/ldn
Melvin Carvalho
@melvincarvalho
Im going to write a processor for individual jobs too.
Sarven Capadisli
@csarven
@melvincarvalho Anytime is fine if you think that it is comformant. We'll have tests sometime this month, so that'll be a bit more proper to check whether the implementations are okay or not. For the spec to go through, we need at least 2 implementations for the required sections in the spec. Right now we are adding the implementations to the list in an informatively. They'll eventually be removed in the final Recommendation, but linked to previous version (CR) which will have the links to the implementation.
Melvin Carvalho
@melvincarvalho
we have more than two implementations already, right?
Sarven Capadisli
@csarven
For the moment, we are going with solid-terms:inbox or ldp:inbox (as per spec), but eventually we'll have one and stick to that.
Melvin Carvalho
@melvincarvalho
it's not hard to have both
coding wise
Sarven Capadisli
@csarven
Yes, we do, but it has to match the MUSTs in the spec.
So, we need to check carefully at some point.
At the moment, we are leaning on ldp:inbox. I think Solid implementations are open to that possibility if the spec is moves forward. Tim felt that it'd be good to put the discovery property under ldp, but solid could work too.
Melvin Carvalho
@melvincarvalho
no strong opinion here
Sarven Capadisli
@csarven
Great to hear that.
We don't have a strong opinion either but feel that ldp will get more mileage / less friction to use
Bart van Leeuwen
@semanticfire
it just needs some form of 'push' to a client for me then I really would love to implement it
Sarven Capadisli
@csarven
@semanticfire Push/poll are indeed useful, but the question that's still up in the air is whether that needs to be defined in this spec or simply refer to something that's out there.
Melvin Carvalho
@melvincarvalho
@semanticfire in solid we use websockets for that
it compliments LDN
but it's not the only way to do it
Sarven Capadisli
@csarven
We certainly don't want to define our own. Neither do we have the expertise but also it just won't work into 'this' spec. It could be referred to some other note/spec.
Melvin Carvalho
@melvincarvalho
I have a few apps with push/pull working
Sarven Capadisli
@csarven
This is not to imply that we don't want to discuss this. IMO, best way forward is to have (sub)section e.g., appendix or under considerations.
Bart van Leeuwen
@semanticfire
yeah i think not talking about it at all is not what you want
although I see that it is out of scope for the WG
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?