LDP, Linked Data Platform, is a W3C specification defining a standard way for servers and clients to interact with resources (primarily RDF resources) over HTTP. In particular, it introduces the notion of Containers, RDFSources, and Non-RDFSources (or binaries).
It may help to think of an RDFSource as a document, kind of like an HTML web page. Only, the content is not HTML, it's a graph (a set of RDF triples) sharing the same subject URI. Together, the triples in this document would typically describe or make up a given entity or object. So, those could be thought of as properties of the object. The document could be expressed in RDF XML, in Turtle, JSON-LD, or possibly other formats. These properties may be literal values or they may be links to other resources.
LDP implements the RESTful architecture, so how you view this RDFSource depends on how you ask for it in your request to the server. If you ask for the resource to be expressed in JSON-LD, you should get back a JSON-LD representation of the resource. If you ask for it as Turtle, you should get back a Turtle representation. This is done by passing certain HTTP headers in the request. Additionally, the RESTful nature of an LDP allows you to use HTTP methods (GET,POST,PUT,DELETE) to interact with the resources in various ways.
A Container is also an RDFSource, but it allows you to manage membership. Containers can have member resources. You could think of a Container kind of like a folder. Only, it doesn't physically contain RDFSources or documents. Instead, it has a set of triples (membership triples) that define or link to its members. You can view a Container as a container or as an RDFSource depending on the preferred interaction model that you specify in a request header.
So, basically, you can think of an LDP as a way of interacting with RDF resources in a way that is similar to a web site with folders and documents. Only everything is RDF, not XHTML. On the back-end, the server may actually manage each resource as a real document (file). Or, as is the case with Carbon LDP, for example, it may put everything in a triplestore (an RDF store / database). Then it just gives you back a set of triples that look like a "document" because they share the same subject URI, which is what you used when making the RESTful request. Since Carbon LDP manages all these "documents" in a triplestore, it can also provide SPARQL query support across everything (though SPARQL support is not part of the LDP spec).
So, in essence, an LDP enables a very "webby" (or RESTful) way of working with RDF data. You make HTTP requests to URI's and they get resolved to resources (Containers or RDFSources), which you can then consume to get at all the triples. And of course you can create resources, update them, list members of a container, etc. In this way, you can build web applications, that use RESTful requests (perhaps async JavaScript or AJAX requests).
One advantage you win is that even though the data you're working with may be very specific to any given application your building on LDP, the REST API you use to work with that data is standard and consistent.
Another advantage is that you're working with RDF, so the properties of your objects, the predicates, can link data across your enterprise or the World Wide Web. This can help you incorporate data and discover things that your app may not have been specifically designed to support. And also, because you're working with the RDF data model, you can use pre-existing vocabularies for your triples, but you don't have near as much hassle with schemas.
In RDF, you can add new triples (new properties or links) without having to update some database schema and the associated code required to interpret it. LDP deals with RDF resources in a very generic way - it doesn't care what the triples that define or make up the resources actually are. When you build an LDP app, you can extend that sort of generic quality into the app in such a way that your data can keep changing and evolving without imposing as heavy costs on the maintenance and evolution of the app itself.
This kind of technology helps you bridge the gap between the current web of hyperlinked documents to a web of linked data, which is easier for computers to understand and interoperate with. For a little more info about RDF and the big difference between a hyperlink and a linked data link, see The Awesome Power of the Link in Linked Data.
You can also find a somewhat technical introduction to LDP in Introduction to: Linked Data Platform, an article I wrote a while back for Dataversity.
