Determining how best to participate in OSLC service discovery

OSLC specifications are often written with the intent to solve some basic integration scenario. Sometimes it is not obvious the best way to apply the specifications to some specific tools. I'll take a look at a couple of bug trackers (Change Management Providers) and see how one might use oslc:ServiceProvider and oslc:ServiceProviderCatalog with them to allow for service discovery.

Let's take a look at a couple of specific installations of Bugzilla: one at Eclipse and the other for Mozilla (Firefox).  The typical partitioning of bugs within Bugzilla is by product.   Eclipse has them grouped by common areas (Classification) as these shown below:

Let's say from this list I want to open a bug against EMF.  I'm presented with either a guided or traditional web page for filling out this form.   From there I pick a Component and provide additional fields needed to complete the form.

So the organization of bugs within Bugzilla are:

With OSLC, we have the possible structure of mapping to any number of oslc:ServiceProvider and oslc:ServiceProviderCatalog.  So what makes the most sense?  We need to look at how our resources are grouped together and restrictions put on that grouping.  A oslc:ServiceProvider contains the URIs to various capabilities a provider has to offer like: resource creation by POST, query, delegated web UIs for creation and selection of resources.  This grouping is usually driven by certain constraints put on these resources.  For example it could be all resources in a given project or product.  The access rights and rules on creations are often isolated to a given project or product area.  From this criteria, the Bugzilla "Product" seems like a good fit for oslc:ServiceProvider.    From here, it would seem natural to have one oslc:ServiceProviderCatalog per Classification.  This would allow someone to get a catalog for a specific Classification and it would lists all the Products associated with it.  So this would give us a picture like this:

The next question one might ask is: how do I know what all the Classifications are?  Since oslc:ServiceProviderCatalogs can reference also other oslc:ServiceProviderCatalogs we can introduce another catalog as the "root" of all these pieces of information.  So the picture would now look like:

So one may be thinking now: what about Component?  Looking at its usage within Bugzilla instances it is more of a "common required property" than what was described before as criteria for selecting a oslc:ServiceProvider.
Some other options could have been done as well.  Not having intermediate oslc:ServiceProviderCatalog but instead list all oslc:ServiceProviders (Products) in a single oslc:ServiceProviderCatalog.  This may have worked fine and depending on how you server partitions its resources, an organization list this could make sense.

Next let's take a look at Google Code's Issue Tracker.  There is only one instance of this server of this code base and it is at http://code.google.com.  Let's look at some of the qualities of the projects there and organizational structure.   As I type this, there are 5,681 projects.  These projects can be tagged to make them easier to find.  Each project has its own issues URL, which can be used to get feeds on issues and POST to it to create a new issue.  As you could imagine, a common way to find projects and issues within projects is by using Google's free-text search.  So given this, it seems like a project would be represented as an oslc:ServiceProvider.   Though it makes me think how many of our existing clients are prepared to deal with an implementation that has an oslc:ServiceProviderCatalog with 5,681 entries.  Within OSLC there is a general-purpose resource paging solution that could help this, which is what I'd recommend.  It may be some time before Google Code's Issue Tracker becomes OSLC-compliant but it may be that someone can easily put an OSLC fascade onto using one of API's that are available.

To be clear, this is only exploring how any some tools may expose their capabilities.  It does not imply that oslc:ServiceProvider represents a product or a projects.  Clients should only interpret these constructs as a way a tool has exposed a path to the oslc:ServiceProvider.  Often the client is driven by a end user who will be presented with choices to select the appropriate one based on their understanding of the current application and with which they are integrating.