OGCWG - Lessons Learned

Introduction

As of October 12, 2012 participation in the Oil, Gas & Chemicals Business Group (OGCBG) has dropped below the point that we consider the Business Group viable, and we have decided to convert the effort into a Community Group. This essay is our take on how and why this has happened and what the options are for the future. In very short form, here is a table showing the features that distinguish a business group from a community group and what our experience has been:

Confidentiality

One of the primary differences between Community and Business groups is that the work of the former must be done in public whereas the day-to-day work of a Business Group can be members-only. Of course the final products of a Business Group need to be made public, but getting the required permissions from the corporate members of the group to publish is part of process of the group, and presumably some care and negotiation may be involved if there are aspects that some companies find potentially sensitive. It was very clear from many comments at the Organizational Face-to-Face Meeting and thereafter that this confidentiality is very important to many or most of the potential corporate participants if the group is to work on an actual business application. Although the participants would presumably be careful in the work process not to divulge sensitive information, most companies have a formal internal process to approve any communication that will become public. It would obviously be impractical to submit absolutely everything that one says in the context of a discussion of a business application for approval, but eventually that kind of information would have to go through the appropriate process. Obviously this most reasonable to do at the end of the process at which time the documentation of the work product would presumably be looked at carefully and suitably sanitized.

So how would this work in the context of a Community Group? Well, of course we have yet to see what can happen, but it seems at least plausible that a Community Group could work on developing a business use case in somewhat general terms with the intention of spinning off a Business Group to work the application in more detail if the level of interest seemed to warrant it.

There is, however, another issue involving confidentiality that may also be a problem for any interaction in a Community Group: the potential presence of the media. There is obviously no way to exclude the media either from direct participation in a Community Group or from viewing all emails and meeting minutes. It has been our experience that companies in this industry sector tend to be extremely careful about contacts with the media for reasons that are perhaps too obvious to dwell on here. Certainly there was considerable concern expressed a the Organizational F2F and thereafter about media exposure. It is unclear at this time how this issue will play out when we convert the group to a Community Group. On the one hand there are obviously existing Community Groups with participants from various industry segments, and there doesn't seem to be a big problem doing this. On the other hand, this industry may be particularly sensitive about this issue.

Fees

When Business Groups were first proposed and discussed many or most people thought that a $10K fee (for a large non-member company) would essentially be "loose change", particularly when compared to the internal cost in time and possibly travel to participate, and that fees would not be a significant barrier to group participation. The reality has been totally opposite, however. There were a number of participants in the Organizational F2F who were obviously very enthused about participating and in fact several expressed a definite intention to do so -- subject to getting the expenditure approved. In fact, only Statoil and Chevron approved it. This was obviously disappointing and perhaps perplexing to many. Although we obviously do not know exactly what happened in these companies we can take some pretty good guesses. In the first place, in virtually all companies expenditures that actually go out the door as a check are treated entirely differently from internal time and travel expenses, and the approval process is generally different and more onerous. There is a LOT more management scrutiny on cutting a check than there is on attending meetings. Another factor may be that most companies are quite cautious about establishing a new relationship with an external organization, even if the up front cost is low, because there is a feeling that often one thing leads to another and commitments grow somewhat unpredictably. Of course, this is the flip side of the same coin which motivates the W3C to encourage participate at a low cost -- because one thing may lead to another ....

What is required for a company to make this sort of "somewhat open ended" commitment? Probably there are three prime requirements: 1)A clear, specific and quantitative demonstration of value from the participation; 2)Active participation from a significant number of other companies from the industry segment; 3)A clear, convincing answer to the question, "Why do this work at the W3C rather than an industry consortium?". We were not able to meet any of these criteria in this Business Group. In hindsight perhaps it might have worked better if we had tried to develop a really convincing use case with clear financial value in the context of a Community Group which did not have a fee barrier to entry, and if enough stakeholders were willing to commit to that use case THEN spin off a Business Group. Of course, it is not clear that we could have done that given the confidentiality landscape of a Community Group, which certainly would have been an issue, and the question of "Why do it at the W3C" might still have been a problem. We will address that issue in the subsequent sections of this document.

Staff Support

Another perceived advantage of a Business Group over a Community Group was that the W3C would provide more staff support for a business group. There was some expectation that participation from staff members who are Semantic Web experts could provide an advantage for doing this work in the W3C as opposed to an industry consortium. In fact, however, we never did get substantial technical support from W3C Semantic Web experts, so this advantage did not pan out as expected. However, in fact we DID get considerable technical support from Semantic Web experts who came to the group from W3C member companies. These were clearly people who do not participate in our industry consortiums, and their input was at times extremely useful. For example, in the context of developing our environmental monitoring use case a participant from Statoil raised an issue related to time series as an "important challenge" with no obvious solution. Somewhat to our surprise, Arthur Keen of Algebraix (A Semantic Web technology company) was able to give an authoritative response which not only said, "This is the best way of handling this problem", but also sited actual experience in the context of a different industry implementing that solution successfully.

We would not like to leave the impression that W3C staff support was lacking. In fact, several members of the W3C staff have been extremely responsive and helpful. In practice, however, most of the issues that they have helped us with have been related to process, legal issues, evangelism and navigating the W3C technical infrastructure. We question, however, whether they would have been any less helpful if we had been a Community Group. The W3C has a very strong culture of cooperation and support, and their people are top grade.

Focus

As mentioned many times above, the focus of a Business Group was intended to be working on a business application of a W3C technology -- in this case Semantic Web technology. The confidentiality of a Business Group is considered necessary to work on the specifics of a business application, but there are probably other things that could be addressed in a Community Group. In particular, a Community Group could focus on information sharing and education or on developing requirements, use cases and value propositions either for business applications or for proposed new W3C standards. In any case, however, one must clearly answer the question, "Why do this work at the W3C rather than an industry consortium". We see three possible approaches to this issue:

1. Staff and/or members of the W3C supply technical expertise not readily available in an industry consortium;
2. The desire is to get the W3C to develop a standard that is of particular interest to this industry, and a Community Group provides W3C visibility and a clear path into the W3C standards process.
3. The use case or technical issue at hand has stakeholders in companies that would not be in an industry consortium.

The technical expertise argument was what we were primarily depending on in this Business Group, and as documented above we got real value from participants who would probably not have been available in an industry setting. However, it appears that not everyone had the same perception of the value of this technical assistance. Ironically, Chevron and Statoil, which to our knowledge are the only two companies in this industry segment to make a program-level effort to use Semantic Web technology, clearly found this argument quite persuasive. It appears that other companies, probably less expert and currently involved in the technology, did not.

As for the other two approaches, this Business Group did not consider any issues that could lead to a W3C recommendation, but we have recently learned that there is some interest both in our industry and some others in promoting a standard Web Services interface into ontologies. Perhaps this opportunity can be pursued in a Community Group.