SoLiD requires LDP about solid-spec

[RubenVerborgh]

I know that @kjetilk has elaborated on his views on the LDP mailing list, I'm sure he can provide you with the right pointers.

However, it's very simple in principle: LDP is a specification document that clients should hardcode. The responses do not indicate how the API should be used; rather, the spec explains this. In contrast, the idea of a REST API is that all agreements are in-band, i.e., that responses explain to a client what it can do on the server.

[melvincarvalho]

Thanks for the feedback.

SoLiD builds on existing W3C RECs (RDF and LDP). RDF has been around for a while, and is steadily gaining traction. LDP is only about 4 months old so far, but has 10 implementations, and remains to be seen how it will progress. It might be a bit simpler than some imagine, it simply gives you a way to PUT and POST linked data in a common sense way, and has the concept of containers, which are like directories but could be used as inboxes or outboxes. Any kind of social API is going to have to standardize patterns for reading and writing activity streams. So part of LDP will need to be reinvented at least.

My understanding of the Social Web Group is that activity streams is looking in quite good shape. But the social API is less so, being quite some ways behind schedule.

SoLiD is the only system to my knowledge, that has implemented any of the user stories using the social syntax ie the activity streams vocab. However, the activity pump proposals seem to show the promise of doing the same. The largest player in the indieweb community (known) has also shown a willingness to potentially support activity streams, and already supports JSON.

Other than uncertainty around the future of RDF and LDP, which is understandable, tho I might suggest also subjective. It's not 100% clear what could be added to the SoLiD spec to address concerns. Id suggest closing this issue and moving it to the chat area, unless there are any concrete proposals on how to fix issues in the spec?

[rhiaro]

It might be that rewriting the SoLiD spec so that dependencies on LDP are abstracted out would help (specifically with regards to it being useful for the SocialWG). So that servers can still be SoLiD conformant, without implementing all of LDP. I guess this would consist of requiring RESTful operations, POSTing and GETing JSON-LD (rather than turtle), and the stuff to do with containers/directories.

I think ACL in SoLiD conflicts with how the AS2 vocab expects audience targeting to be done, but that's probably a different discussion.

@melvincarvalho, you have mentioned the SoLiD 'implementation' using AS2 before and pointed to https://github.com/linkeddata/solid#brief-example-of-solid-in-action, which is a description rather than an implementation (and ActivityPump has the same from the Paris meeting). Could you instead link to code for a working implementation, and links to the blog posts created in this way?

As an aside, I don't recall seeing Known mention anything about supporting AS2 - I may have just missed it - could you link to a citation?

[kjetilk]

LDP most certainly isn't RESTful, there are just some parts of it that are RESTful, but you can't make LDP completely RESTful as it stands. You can't even get started, because there is no RESTful way to authenticate. :-) So, at the very least, you need to wrap the thing. With REST, it is of fundamental importance that you make all that the application needs in-band, not in a spec like LDP.

We had a discussion about LDP in the Developers Workshop at ESWC earlier this summer, recorded here: https://www.youtube.com/watch?v=F4WN4XEpViA

I won't comment on the details of SoLiD, I don't know them, but tying things to LDP sounds like a bad idea to me... :-)

[bblfish]

Now, I fully agree with the general sentiment of orthogonality, which I believe was @rhiaro 's point as well, that the connection between SoLiD and LDP is problematic exactly because it is a point where orthogonality should be maintained.

Well SoLiD is showing how to put together all the different pieces and specs in order to create a distributed social network. The pieces individually are orthogonal, but at some point it is important to show how they all work together, and that is what the SoLiD project is about.

but also at the more general lack of REST in it.

Before you go off an try to re-invent what people have allready done, it may be worth if in another thread you explain what you mean there. I have read Roy Fielding's paper and have worked on the web for 20 years and don't see any problems with REST there. In fact quite the opposite.

[kjetilk]

Right! And the thing is, to be RESTful, all those question MUST be answered in the messages passed between the client and the server. If it relies on an external spec to do that, it is not RESTful, period.

Besides, LDP doesn't really answer that, does it? I mean, if I POST to an existing resource, there are many ways to merge two RDF graphs... But now, I really will shut up. I promise. :-)

[bblfish]

@RubenVerborgh wrote

In contrast, the idea of a REST API is that all agreements are in-band, i.e., that responses explain to a client what it can do on the server

That is exactly what happens with LDP. If you find an ldp:BasicContainer then you know how you can interact with it to create a resource. If you have a Direct or IndirecContainer the client knows the same but knows about a side-effect that will happen as a result of the creation. You also know what will happen on deletion of an LDPR., etc... All of that works with no out-of-band knowledge needed ( though I have a few issues open for the current SoLiD spec that currently require out-of-band knowledge ( see issue #35 and #34 ) )

It is really basic, but it is enough to do a lot of what is needed. The rest of it is all hypermedia based, ie: clients can follow links based on the semantics of them. That is why RDF is also known as hyper-data. And that is why this is a hyper-media protocol.

[bblfish]

If you find an ldp:BasicContainer then you know how you can interact with it to create a resource.

…because you read the spec. Clients cannot know with ldp:BasicContainer alone what they can do.

A client needs to just know what the meaning of the relations are yes. That is all that is required of a hyper-media based protocol.

Frankly I don't see how it could work any other way.

[RubenVerborgh]

one can do a huge amount with the simple abstractions provided by LDP.

Sure, you can build a lot of systems on top of a specification for collections. Just like lots of things can be built on top of Atom. But it remains the case that LDP works by specifying everything in a separate specification document rather than explaining in-band to a client "this is what you can do and how", which is the point I brought up.

provide a use case in a separate issue where the problem you are describing pops up.

LDP is not useful for anything that does not act exactly as LDP, because clients and servers rely on a hardcoded contract/specification instead of having servers specify in-band how clients can use them, as we do on the human Web. Note that this is just an observation, not a judgement. I'm fine with LDP not providing this information in-band, and there's lots of things you can do with that.

However, compare this to explicit approaches, such as the one sketched by Kjetil here or the work of the Hydra community group. In short: hypermedia-based solutions deliver the building blocks to express hypermedia controls (which clients should indeed understand), and these building blocks allow building multiple APIs. Spec-based approaches deliver a specific give-or-take contract clients and servers should implement. I see more potential in self-descriptiveness in the longterm: servers that tell clients what they can do—exactly how it works on the human Web. Our websites also don't say "I implement X", and we don't have to read the X document to know how to use the website. They provide links and forms, and those might well be different for each site. But the usage documentation (affordance if you like) is in-band.

Highly relevant: @mamund on hypermedia

[sandhawke]

IMHO LDP should have a loosely-coupled (RESTful) modular design, but alas it doesn't.

More details: https://lists.w3.org/Archives/Public/public-ldp-wg/2014Nov/0051.html

Going forward, I suggest LDP be re-factored into a loosely-coupled set modular elements. I think this would also help a lot with convergence with micropub, etc.

[bblfish]

LDP can easily be refactored into simpler components without breaking the semantics, and better documentation can be written for it. At the base it is pretty simple. But to stop at that is to stop at a superficial problem.

I have spent 6 months with young developers in a startup from Oct 2013 to Mar 2014 building User Interfaces on my LDP implementation rww-play. The major problem there was not the complexity of LDP it was to get them to believe in the project of a distributed social network, in the philosophy of the semantic web etc.... Ie. the difficulty was to operate a paradigm shift. The problem that we are tackling has not be tackled before and that requires one to think differently about a lot of the tools one uses.
You can't just take young people call them by the derogatory name "script kiddies" and hope to get anything much out of them by pointing them at any specs. Because in this case it requires new ways of conceiving of how to build the web in a RESTful way. But once that paradigm shift has been made through cool applications then it will be easier and easier for people to join the crowd.
This is very much like before Google Mail came out. Nobody before had written any single page JS applications even though for 5 years previously it had been possible. It was just not something people thought about. It was not that easy either as one had to think through a lot of issues. But nowadays writing single page applications is extreemly wide spread and there are industries building tools for people. What is simple depends a lot on the tools you have available and know about, as well as your understanding of how to solve the problem.

Anyway once I had operated the paradigm shift, and got enough of an initial traction, we got very quickly to build applications, even with the pretty alpha quality JS tools we had at the time. One of the developers had no serious prior JS experience by the way. In three months we got going from nothing we ended up getting some pretty good initial demo going, and I learnt a lot about JS and UI design in the process.

The problems of building distributed tools is just to solve the problems one by one and to not give up at the first sign of a problem. It is like learning to ski. Give me young clever developers for a year or two and we'll get very very far. LDP is certainly not a problem in this space. It is a pretty good, though very simple building block and it has 11 implementations.

[melvincarvalho]

@bblfish @sandhawke agree that creating running code is way forward. Facebook and uber apps are excellent ideas. SoLiD despite being less than 6 months old has also made a great showing in the user stories.

Most importantly IMHO SoLiD is this only technology with a strong enough foundation to build a browsable social graph, something that became clear as desirable as early as 2008 in the group run by David Recordon (Social Network Portability). This has also been the bedrock of facebook's platform, so I think porting a social network to SoLiD is a very promising proposal. No other technologies has made progress in rich social graphs, and SoLiD is distributed.

Regarding the other "approved" use case SoLiD has probably implemented as many as the rest of the WG put together, in a fraction of the time, without having a dedicated person to do so (ie spare time projects). With one full time person, the vast majority of the user stories could be implemented, in the life time of the group, we just dont have that person (volunteers welcome!).

See: https://github.com/w3c-social/social-ucr

These are also things that other large teams have taken years to do. SoLiD work on the user stories actually has had to slow down while waiting for others to catch up. SoLiD is the only technology to have implemented the common user story ("Sending a Note") using WG social syntax (Activity Streams 2.0). Because the group is moving quite slowly on some of its deliverables, it leaves developers wondering how productive a use of time it is. Additionally, there are user stories with say 15 +1s which will be torpedoed by a single person whose technology struggles to cover it, preventing even consensus on which stories to implement, and slowing things down. Some of the people in the group still dont even agree on using JSON as a social syntax, even though it was in the charter.

Creating SoLiD apps is easy. In the sense that Angular JS is easy. Having evaluated both technologies (I may be a bit biased here) I think SoLiD is easier than Angular. What really hurts SoLiD is criticism by people (normally that have never seriously used it). I was able to build 5 test apps in 5 days, while still learning the technology.

In the last week I've built the skeleton of a payment app with website and web of trust. In the last day I've built an app that can stream you paragraphs from books that you can read during your spare time. Im going to add sharing, payments, ratings and playlists next.

There's so much that can be done with this platform, that no other platform can come close to. A single developer can make a big difference. Id much rather hear criticism of things people cant do than theoretical or subjective objections.

One thing we can learn from comparison is the high volume approach taken by activity pump. SoLiD doesnt (yet) have high performance patterns to aggregate, search, get partial content. archive etc. What I'd love to see is when others complete the user stories, would some performance testing and benchmarking etc.

[BigBlueHat]

@akuckartz quick note on the "LDP seems to violate the HATEOAS constraint and therefore is not RESTful" comment and the link you posted. Per the Richardson Maturity Model (fwiw), LDP would be a "Level 2" RESTful API. Obviously, getting to Level 3 gets you, in Roy Fielding's words, "architecture on the scale of decades." Which is nice. 😉

I wouldn't go so far as to say LDP "violates" HATEOS, but simply doesn't implement it. There's nothing holding anyone back (afaik) from using LDP to build a HATEOS implementing API that uses the LDP semantics as a foundation for shipping around "Hyper Turtle" 🚀 ➕ 🐢 😄

If there are things in LDP (or even Turtle...as the default media type) that would prevent or complicate the use of hypermedia on top of LDP, then that should be discussed in earnest, but afaik, that's not the case.

Turtle is on @mamund's list of Hypermedia Types fwiw: http://mamund.com/hypermedia/
And it could certainly have RDF Forms and what not encoded in it thereby enabling more of the "h-factors": http://amundsen.com/hypermedia/hfactor/

So, LDP comes in at a "Level 2" RESTful API. SoLiD could be a "Level 3" if it wants to be (and maybe it already is)--but that's up to y'all. 😃

Certainly this will come up at @RESTFest since @jasnell's our keynoter, so any more thoughts the SoLiD group or the Social WG is generating on this topic would help inform the hack day and lightning talks given that weekend. It'll certainly help inform mine. 😄

Lastly, thanks for caring about REST @akuckartz (et al)!

[melvincarvalho]

@rhiaro thanks for raising a number of different points, as you say ACLs are a topic in itself, if you are in search of implementation details I would recommend running GOLD or ldnode, and using the curl examples. I've been doing this on my own box for quite some time. We are trying to encourage as many people as possible to give that a try. I appreciate the examples are in turtle and you may be working with JSON LD, however I do believe that SoLiD implementations support JSON LD and turtle / JSON LD can be converted to each other via the JSON LD playground : http://json-ld.org/playground/

Regarding the OP abstracting LDP into generic read and write RESTful operations is an interesting thought, however, I think this is largely what the LDP working group spent the last 3 years doing. They did have some experts from the REST community in that group too. If you feel there's a better RESTful way to create such abstractions, a proposal could be interesting, however there is a likelihood that it may be duplicating some of the work and investigation done by the w3c during during the creation of LDP.

I'm unsure it's going to be practical to remove LDP from the SoLiD specification (I could be wrong on that), the social web wg is still very much in brainstoarming mode for any kind of API, so I suggest closing this as a SoLiD specific github issue, as Im not sure what in practical terms can be done to help.

Perhaps moving this discussion to a more brainstorming type forum, such as one of the chat/irc areas or mailing lists or wiki would help to flesh out some of these thoughts further, with a view to making specific improvements.

[akuckartz]

@rhiaro writes

it occurs to me that as SoLiD mandates the use of an LDP stack, it's not suitable as a candidate for the SocialAPI that the WG needs to come out with. I don't believe that the WG's recommendations will get much uptake if they dictate, for example, what database developers implementing social applications must use. On the other hand, the work on SoLiD is really useful for any developers who do want to use LDP-compliant servers.

@melvincarvalho writes

Regarding the OP abstracting LDP into generic read and write RESTful operations is an interesting thought, however, I think this is largely what the LDP working group spent the last 3 years doing.

This is an important issue. I fear that this objective conflict can tear the WG apart. The resignation of @bblfish from the WG both indicates that and is part of it. I can not offer a simple solution, but I am convinced that the issue should be addressed head-on.

[bblfish]

@rhiaro wrote:

I don't believe that the WG's recommendations will get much uptake if they dictate, for example, what database developers implementing social applications must use.

LDP makes no requirement about the database that must be used. rww-play saves files to the file system for example ( and it serves JSON-LD) . LDP is a protocol and specifies interactions between client and server, not how data must be stored. This was discussed by the LDP list of this, and many players made sure they ensured it would be useable with SQL databases, and other non SQL-databases too.

[rhiaro]

Poorly phrased example, but thanks for explicitly clarifying that @bblfish, that's helpful.

[bblfish]

@kjetilk It would be more helpful if you put up the questions you address in your ESWC recording as individual issues here ( with perhaps pointers to the recording and the places where you go into them). We can't in this thread answer in general a one hour discussion you had some time ago, not knowing if you still agree with the questions you had.

As an example you start off with arguing how problematic it is that LDP does not say anything about access control. That is true, but that is a good thing, as specs are meant to be focused and do one thing well. The proof that this is not a problem is that SoLiD does address access control orthogonally to LDP, with WebID and WebAccessControl ontology.

[kjetilk]

So, my criticism is directed towards LDP, and a very superficial attempt at programming with LDP, which failed because it didn't address the very basic question of authentication, but also at the more general lack of REST in it. Now, I fully agree with the general sentiment of orthogonality, which I believe was @rhiaro 's point as well, that the connection between SoLiD and LDP is problematic exactly because it is a point where orthogonality should be maintained.

However, I shall admit that your point that there is nothing wrong with LDP because the orthogonality with authn-problems are met with WebID and WAC, is well taken. Perhaps you're right. Now, the thing is that I have this plan in my mind for replacing LDP entirely with an ontology to establish that hypermedia I think should supersede it, but clearly, I should shut up until I have code to show. :-)

[deiu]

@kjetilk from what you're saying I'm under the impression that you misunderstood what LDP does, and also that you lack familiarity with SoLiD. LDP is not supposed to provide a complete solution for building a full service, one that includes identity, authentication, and access control. LDP does one thing and it does it well. It gives clients a way to read and write data on the Web, by manipulating the resource URIs themselves. To me that is one of the core principles of REST, and the reason why SoLiD uses LDP.

[kjetilk]

@deiu the thing that bothers me about LDP is just that sentiment that LDP shows how to read and write data. HTTP does that, and has done that since the dawn of ages. :-) LDP seems to complicate things. But I'll shut up and leave it to @rhiaro to further argue for her own point rather than me derailing the discussion into a pro-contra-LDP discussion. Sorry about that!

[deiu]

HTTP handles the _transfer_ aspect of reading/writing data on the Web. For instance it doesn't tell you what should happen between two machines when a client sends a POST request. Should the server create a resource or append the data to an existing one? Is it supposed to create a regular file or a directory? Also, what happens when the client sends a GET request that maps to a container (i.e. a dir) on the server? Is the server supposed to return all the contents of that dir? Inline? What if the list of contents is huge, should it do paging? How?

[deiu]

I personally think this thread if useful, even if it's just to help others clear some misunderstandings.

Of course, LDP answers those questions. That is the whole point of the spec. It doesn't describe how to merge two graphs, because that is an implementation-specific operation performed by the server. LDP is really basic (on purpose). It gives clients a standard set of instructions on how to _manipulate_ resources on the Web. That's it, really.

[akuckartz]

@kjetilk I would really like to completely understand your comments, but I do have problems understanding some of your arguments. Can you provide a link to a more comprehensive text I can read which explains how LDP violates REST constraints?

@RubenVerborgh @lanthaler I also would be interested in your views regarding this question.

[kjetilk]

My comments on LDP mailing list is so ancient, they don't count anymore (actually, I'm not sure I voiced them there, it might have been the SPARQL Graph Store spec, which I helped initiate, but fell into the same problem (IMHO)). But @RubenVerborgh says the essence, it is really that simple; Hardcoding vs letting the responses speak.

You might well blame Roy Fielding for it, if you like, He has said his dissertation is the authoritative reference on what REST is, and it is really not easy to make out this "it is all in the messages" idea, and yet, it is of fundamental importance to the REST idea. The best hint you get is probably in this sentence:

The model application is therefore an engine that moves from one state to the next by examining
and choosing from among the alternative state transitions in the current set of representations.

I wish Fielding had made a new conference paper where he explained this better, so that at least the academics amongst us have something to point to. :-)

Just as an aside: I'm not saying that hypermedia is the Right Thing to do Always. I'm very much a SPARQL guy, and SPARQL is an example of something that is not RESTful, and I think it probably never will, because it relies on a complex language that probably doesn't even make sense to try to express in a message. But I think that for the stuff that LDP does, the design should have been based on hypermedia from the start.

But then, I'm also a big fan of people just doing things that can be done Right Now, and don't wait for someone who says they have the ideal solution somewhere in an uncertain future. Therefore, please don't let this discourage you!

[deiu]

BTW, thanks for having this discussion. I believe it will be very helpful in the long run! :)

I understand now what you mean by "not being RESTful". I think the reason why LDP doesn't use an in-band protocol is because it's not supposed to act like an API. It is operating at a lower level, somewhere in between HTTP and an API, where the equivalent for the in-band signaling is done through headers.

I hope I'm starting to make more sense now...

[RubenVerborgh]

If you find an ldp:BasicContainer then you know how you can interact with it to create a resource.

…because you read the spec. Clients cannot know with ldp:BasicContainer alone what they can do.

[RubenVerborgh]

Frankly I don't see how it could work any other way.

An explicit and reusable vocabulary that describes what the thing does. The LDP mindset is: “the spec says dp:BasicContainer can do this and that". Self-descriptiveness means adding to the response "with this container, you can do this and that and here's how."

[bblfish]

@bblfish wrote:

If you find an ldp:BasicContainer then you know how you can interact with it to create a resource.

@RubenVerborgh replied

…because you read the spec. Clients cannot know with ldp:BasicContainer alone what they can do.

@bblfish responded

A client needs to just know what the meaning of the relations are yes. That is all that is required of a hyper-media based protocol. Frankly I don't see how it could work any other way.

@RubenVerborgh answered:

An explicit and reusable vocabulary that describes what the thing does. The LDP mindset is: “the spec says dp:BasicContainer can do this and that". Self-descriptiveness is adding to the response "with this container, you can do this and that and here's how."

But a client would still need to know what that vocabulary means then! Your answer does not solve the initial problem you posed - that a client will need to know a vocabulary - it just pushes the requirement on the client to know yet another vocabulary.

And also LDP does not say that the LDP vocabulary is all that a client needs to know. Clearly a client that wants to display data about friends of friends in a more than graph like user interface also needs to know what say the meaning of the foaf ontology is. In a Direct or IndirectContainer the client also needs to know the meaning of the membership relation.

What you seem to want is for the server to offer more features than those allowed by LDP. You could try to bring that to light by pointing to the Social Web Use Cases in a new issue and explaining why LDP and SoLiD cannot provide what is needed. That would allow us then to look at the use case and see if that claim stands. (My guess from actually working with LDP over the past few years, is that one can get very far with the minimal structure offered by LDP.)

[RubenVerborgh]

But a client would still need to know what that vocabulary means then!

Yes, but that would then be a generic hypermedia vocabulary that extends to many use cases and allows APIs to describe themselves instead of pointing to a spec that explains this.

[bblfish]

But a client would still need to know what that vocabulary means then!

Yes, but that would then be a generic hypermedia vocabulary that extends to many use cases and allows APIs to describe themselves instead of pointing to a spec that explains this.

Our claim, and the working examples provided by @deiu, @melvincarvalho, @timbl and other here is that one can do a huge amount with the simple abstractions provided by LDP. It would be worth studying those to see how they actually work, before claiming that one needs more.

But perhaps you have studied them. In that case please provide a use case in a separate issue where the problem you are describing pops up. It is not possible to get any further with a discussion at this level of abstraction.

[melvincarvalho]

@RubenVerborgh thanks for your insights. I think it's well known to everyone in the group that specs contain out of band knowledge, to varying degrees.

Depending on your philosophy you can try for the "one spec to rule them all" approach to hypermedia (btw im not sure hydra is that) or you can have a bunch of useful modular specs that stand on their own right. I'd personally rather not have any specs at all, but we've learnt over time that specs are useful to build things.

I agree with @bblfish that the degree of abstractness of this conversation makes it challenging to make progress, if indeed, we are trying to move in any direction. I think I agree with most of your points, tho of course LDP can stand on its own and be used for subsets of LDP functionality such as GET or PUT.

I do think an outsider looking at this conversation might find abstract pro and con arguments over a tech that has not been tried a little strange. Id encourage you to try out the tech in order to offer more specific ideas, which would be welcome. I would personally use LDP for some things, SoLiD for others and Hydra for describing APIs.

[akuckartz]

I found the old discussion about RESTfulness of LDP. It took place in November 2012 (the LDP FPWD was published on 25 October 2012).

There is single mail from @kjetilk :
https://lists.w3.org/Archives/Public/public-ldp/2012Nov/0002.html

And a longer thread starting here:
https://lists.w3.org/Archives/Public/public-ldp/2012Nov/0007.html

The LDP FPWD states that it builds on this member submission:
http://www.w3.org/Submission/2012/SUBM-ldbp-20120326/

[akuckartz]

My opinion:

• Social APIs should be RESTful
• LDP seems to violate the HATEOAS constraint and therefore is not RESTful

Does anyone have suggestions how those two items can reasonably be combined?

[melvincarvalho]

I am unsure this is a major issue. Most REST APIs are not actually RESTful. Here is some background reading:

"Your API is not RESTful"

https://www.danpalmer.me/blog/your-api-is-not-restful

A better question might be to ask which aspects of REST you would like to encourage, why, and how it relates to the user stories of the group. Then we could look at how we might be able fix it?

[kjetilk]

Speaking in general, I think that one need to consider the audience. I have the feeling that LDP is directed towards a small audience of rather capable, technical, people, whereas I think that something basic, simple, RWW semwebby stuff, that LDP pretends to be, also judging from the comments here, should be directed against the armies of JS kiddies out there.

What I want to see is something like what I saw back when I first authored my first HTML page back in 1994: "View Source" and then thinking: "oh yeah, I can do that".

My gut feeling is that LDP hasn't been tested on those JS kiddies, and no-one has ever seen their faces light up as they think "I can do that".

Perhaps they don't have to look at LDP, perhaps some library wrapping it, written by a technically more capable person, would do what they need, but in that case, stop thinking about LDP as being simple.

And to me, you don't need to think in terms of representations and state diagrams, or orthogonality, or web-scale deployment or any of that to appreciate HATEOAS. Think about it as something that enables the rookie web programmer to "View Source" and then feel the thrill of thinking "I can use that!"

[kjetilk]

Sorry, "JS kiddies" wasn't meant in a derogatory way, we've all been there (even if it was before JS).

So, I've been trying to end the debate several times now by saying that I do respect those who are actually building things greatly, and given the fact that I don't have code to show and I fully recognize that running code is the only thing that could really make a difference, I'm thinking that we should just stop talking now. I don't want to come across as a talker and not a doer, but I suppose that's what I do right now. :-)

I do not doubt you can get very far with LDP if you have some clever developers for a year or two, I'm just forwarding some principles that could get those who are not mentored by anyone going too. However, as principles doesn't help anyone as much as running code does, I recognize that these are of little value, in particular compared to 11 implementations. So, please, go ahead.

(However, "script kiddies", is rightfully a derogatory, a script kiddie is someone who is destroying other people's systems simply by running known exploits already packaged as scripts. Now, even they have a role in the ecosystem, but that's a different and long discussion)

[bblfish]

@kjetilk thanks for the input. I am on holidays in Austria right now getting back into shape: mountain climbing with my little 10 month daughter on my back and exercising my brain on Homotopy Type Theory. I'll be back to coding slowly as we get closer to September.

I think the best way to proceed is to attack the Social Web WG use cases one by one, and see how far we get with what we have now laid out in SoLiD. Then as we implement we'll start seeing pieces that are missing, and it will make sense to solve those issues. Perhaps we find a constellation of issues that cannot be solved without some larger piece, but then we'll have a reason to deal with that, and we'll understand why we have to do that.

[sandhawke]

@bblfish, as a slight variation on working through the SWWG use cases, one might attack the problem of replicating interesting/popular applications. Tim's inclined toward meeting schedulers & issue trackers, I'm inclined toward Facebook and Uber.

[akuckartz]

Additionally, there are user stories with say 15 +1s which will be torpedoed by a single person whose technology struggles to cover it, preventing even consensus on which stories to implement, and slowing things down.

If that is slowing things down significantly, than that should be dealt with by the WG.

Some of the people in the group still dont even agree on using JSON as a social syntax, even though it was in the charter.

We will see what happens on Tuesday, when my proposal to replace application/activity+json by application/json+ld plus profile is on the agenda.

There's so much that can be done with this platform, that no other platform can come close to.

I agree that this is an important factor in deciding on how to proceed.