Linking your data into the mix: writing providers/consumers

Body

One of the promises of Linked Data is that it's open: your data can participate on an equal footing with what others expose.  Doing that requires either buying or writing code (sorry - no free lunch).  A number of our products now expose linked data, especially where we know there is a need to integrate with other products and other parts of the ecosystem, and more are coming (just look at the open betas).  Business partners and clients can play as well; half of our Pulse 2013 integration center spots were partners.  All of us have in-house applications too, and we'd like them to play - here's how.

1. Get the general lay of the land.  The OSLC community recently updated their "Participate" page so it's easier to find the (already existing) Tutorial and lays out several more steps in a basic education path (see left nav bar).  While not all linked data is necessarily in an OSLC namespace, everything you see here is generally reusable.
2. Make your data visible in the management system. 
   1. OSLC uses the concept of a ServiceProvider resource as an anchor through which your data is located.
   2. When working with Cloud and Smarter Infrastructure (nee Tivoli) systems, you register your service provider resource with the Jazz for Service Management Provider Registry. 
   3. If your data is one view of a resource with many aspects (everyone's favorite example: computer system), then you'll also want to register the data in the Jazz for Service Management Resource Registry.  As long as what you register reconciles with data from other providers, the Resource Registry will link your data with "theirs" automatically.

Part of that is making some implementation choices.  Depending upon your platform, you might be able to exploit one or more of the open source components.  Which reminds me: we've been seeing a common misconception lately... people see that some of the source code is hosted in the Eclipse Lyo project, and leap to the (erroneous!) conclusion that therefore it requires Eclipse.  This is simply not true in the large.

By the way, most of our product linked data implementations are using the OSLC4J SDK hosted inside Eclipse Lyo.  The ones that aren't are products with little or no Java code in their base, so they preferred to RYO and keep a single language code base.  One of the reasons we're attracted to linked data generally is that it's focused on the wire interface (HTTP) not the SDK interface; so if you want to use a new or "unusual" implementation language, nothing gets in your way.