OSLC's motivation on the design of the LDP Container

It is often that when some concepts in specifications exist, it is hard to tie together the learning from past experiences and what had been considered prior.  Sometimes preserving this and providing the background is too much filler for some already long documents, so I will use this opportunity to pull together a series of activities.  Some of these activities can be found in OSLC 1.0 specs and elsewhere.

All these approaches were motivated with a set of requirements which are quite similar:

• Common patterns for dealing with multi-valued properties
• These multi-valued properties often become large
• Easy way to get all the properties
• Easy way to add new property values

Below are a sample of approaches

OSLC CM 1.0 - @collref

In CM 1.0, when these patterns first evolved and we were working on applying REST we came up with a concept of @collref which was an XML attribute that held the value of the URL of the collection where you could POST to add new members and GET on to get a list of all members.  This approach was developed based on some legacy XML and pragmatic need to solve a narrow problem.  It would for a good number of cases but was a bit special and non-standard.

OSLC CM 2.0 - multi-value props

In CM 2.0 and Core 2.0, we took a more RDF-view of REST and simply treated these as multi-valued properties or in RDF terminology they were same-subject and same-predicate triples.  They were just like any other property on a HTTP (OSLC) resource, using GET to fetch the representation of the state of the resource, POST to create it and PUT to update.  This approach worked well in that it didn't require any new invention but was limited by what existed, it would be good if we could layer on semantics without losing the simple usage of RDF to define the resources.

OSLC CM 3.0 - multi-value props + LDP Container

In drafts of CM 3.0 and Core 3.0, we look to build off a concept called Linked Data Platform Container defined by Linked Data Platform 1.0.  This isn't far from what we've done in 2.0 except it is based on a W3C specification and has some additional semantics, namely layering on the ldp:Container semantics.

Other motivation

Another key scenario motivating similar requires is dealing with things such as query results or filtering long lists of resources and where to POST to create new ones.  In Core 1.0 and 2.0, we used concepts such as query capability and creation factory to meet these needs.  As we see with ldp:Container, this provides that same function while we can annotation it to provide some of the additional needs for knowing what kinds of resources a server will accept in a container it hosts and things like Web UI dialogs that can be used to select and create resources.