Considering the right solution to your integration problem

So often we often get tied up in a specific subject or technology area it feels like we see this is the everything it is just to help people think different.
only game in town.  It reminds me of the Jim Carrey film "Yes man" (by the way, I relate all my work to Jim Carrey films -- please no "Dumb and Dumber "references ;-) where he takes part in a program to change his life by answering "Yes" to any question or opportunity.  He learns, it doesn't apply to all situations but just trying to force people to see a different perspective by opening up to a new way of approaching situations.

I relate my work in OSLC and Linked Data work in a similar way.  It is not the only solution but thinking this way, apart from some traditional ways of thinking about integrations, helps to find alternative solutions that could end up being more loosely-coupled, scale better and are more resilient to upgrades.  Other benefits are that it allows the data to stay where it can be properly protected via access-control and updated as needed.

Often people and companies are so passionate about a technology or solution, they often answer the customer's question before they ever fully hear what the problem is.  There are varying degrees of this, of course if your job is to sell a product then that is then it is hard to imagine that you'd recommend an alternative solution.  Though I think if you worked with the customer to determine it isn't the right fit or the trade-offs, they would be more willing to continue to attempt to business with you.

There are so many factors on deciding what is the right integration solution for your current integration problem.  It would be fantastic if I could clearly define a concise decision tree that fit on a cocktail napkin and handled 90% of the cases...unfortunately, it is not that easy (and a group of integration consultants might hunt me down).  I've worked with a number of customers to identify possible solutions to either simple 1-to-1 integration problems to defining a corporate integration architecture/approach and plan.

Here's some factors that I typically consider to drive a recommendation:

• problem statement & user stories, including any other constraints
• # of tools
• anticipated growth or consolidation
• integration technology already available in tools landscape
• ability to develop integrations
• timeframe and ownership

As I come up with more, I will add to the list but I'd be interested to hear what other considerations people have when tackling integration problems.  I'd like to elaborate more on each of these points and weight them compared to each other as well.

Creating Containers in LDP, it is just this easy

I've heard a number of times that it isn't very clear how one creates a Linked Data Platform (LDP) Container.

Let's start with an example of how to create a simple resource (say LDP RDF Source).  You need to know a URL that accepts POST of the media type you want.
Here's the POST request:

1:  POST /netWorth/nw1/liabilities/ HTTP/1.1  
2:  Host: example.org  
3:  Accept: text/turtle  
4:  Content-Type: text/turtle  
5:  Content-Length: 63  
6:    
7:  @prefix dcterms: <http://purl.org/dc/terms/>.
8:  @prefix o: <http://example.org/ontology>.
9:
10:  <> a <http://example.org/ontology#Liability>;
11:       dcterms:title "Home loan";
12:       o:value 200000.00 .
13:    # plus any other properties that the domain says liabilities have  

(Example "borrowed" from LDP spec example)

s Very simple, just POST some Turtle to a URL.

Now let's look at what it would look like to create a Container:

1:  POST /netWorth/nw1/liabilities/ HTTP/1.1  
2:  Host: example.org  
3:  Accept: text/turtle  
4:  Content-Type: text/turtle  
5:  Content-Length: 72  
6:  Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type"  
7:  
8:  @prefix dcterms: <http://purl.org/dc/terms/>.
9:  @prefix o: <http://example.org/ontology>.  
10:
11:  <> a <http://www.w3.org/ns/ldp#BasicContainer> ;
12:       dcterms:title "Home loans" ;
13:       o:limit 500000.00 .   
14:    # plus any other properties  

That's it, just POSTing some content just like before. I added a Link header (line #6) on the POST request to be explicitly clear that I want this newly created resource to behave as an ldp:BasicContainer. Note that I wanted to be expressive so I included the type triple on line 11, though the spec doesn't require this as the Link header as the spec-defined way to clearly assign the desired behavior.

There are various other ways that ldp:Containers can come into existence, most of those reasons are dependent on the server's application-specific rules.  For example, an application might allow the creation of a resource of say "Customer", the application logic may determine to create a number of supporting Containers for the new Customer resource, such as which assets and liabilities they have.