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:
So the organization of bugs within Bugzilla are:
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.