Abstract

The World Wide Web Consortium (W3C) is an international consortium where Member organizations, a full-time staff, and the public work together to develop Web standards. Our long term goals are:

• Web for Everyone: W3C wants to make the benefits of the Web available to all people, whatever their hardware, software, network infrastructure, native language, culture, geographical location, or physical or mental ability.
• Web on Everything: The number of different kinds of devices that can access the Web has grown immensely. Mobile phones, smart phones, personal digital assistants, interactive television systems, voice response systems, kiosks and even certain domestic appliances can all access the Web. The goal of W3C's Mobile Web Initiative, launched in 2005, is to make Web access from any kind of device as simple, easy and convenient as Web access from a desktop.
• Knowledge Base: The Web is not merely an immense book where people can search, browse, and view information. It is also a vast database that, if designed carefully, can allow computers to do more useful work. By developing a Web that holds information for both human and machine processing, W3C aims to enable people to solve problems that would otherwise be too tedious or complex to solve.
• Trust & Confidence: One of the long-term goals of W3C is thus to promote technologies that enable a more collaborative environment, a Web where accountability, security, confidence, and confidentiality are all possible, and where people participate according to their individual privacy requirements and preferences.

W3C has a great interest that cloud and grid computing will connect to the Web the right way. Semantic Web technologies liky OWL ontologies and RDF metadata for services are one of the very important tools to overcome current shortcomings in metadata representation in services. This presentation will give a very brief howto on connecting to the vibrant W3C community. This will allow projects to do the right thing and reach out to a world wide community.

Standardization can best be understood as the process aiming to define common and mutually agreed (technical) solutions between relevant stakeholders, for the benefit of all involved. It will help encouraging the free movement of goods, thus help to remove technical barriers, open up new markets, and enable new economic models. Working with all stakeholders helps to create economies of scale while at the same time increasing opportunities for product differentiation and competition and services.

Economies of scale create so called economic network effects. If a technology has reached a certain scale, the benefit of participating and the economic value of having a stake in that technology increases with every new participant. In more popular terms we often refer to this effect when saying a technology takes off. Those economic network effects have a huge impact, but are also very hard to generate. On the Internet, one stakeholder (even a big IT company) alone is almost unable to create sufficient impact, awareness and growth to reach the bar necessary to create such network effects. Working together in Working Groups to develop common grounds and pushing a certain technology together increases the chance of having real impact and recognition.

Much research today is based on the existing infrastructure. While basic research may also question the fundaments of the infrastructure, it is unlikely that it will be deployed unless it has disruptive huge benefits and a sound basis in commercial interest. This means applied research is well adviced to base incremental innovation on the existing world. This infrastructure has its own rules and constraints. But the constraints can be extended, features added. This is done in the relevant Specification Developing Organization (SDO). The connection to the relevant SDO should be done already in the project planning phase.

Sometimes, SDOs can be a great facilitator for technologoy transfer. SDOs generally provide good connection to the industry. Some research projects are closer to applied research and could greatly benefit of industry leverage. Going to an SDO and using that platform to develop something jointly with the industry can create great synergies. Deliverables can be used as direct input to the SDO and can thus benefit from greater scrutiny and outreach. With the help of the industry, critical mass can be reached. But this requires flexibility from the SDO, the project and the industry to leave the usual paths in their respective domains.

Promotional efforts aim to create maximum awareness of a project's objectives, goals and benefits among its main target groups: IST research projects, standardization working groups and relevant industrial organisations. Dissemination of project's results through standards bodies in general brings projects higher international recognition, collaboration opportunities, and the ability to cooperate with a variety of specialists, thus benefiting from their collective expertise. This will lead to an additional validation process by a wider expert audience that may be closer to the market. These experts well understand standards' key role in encouraging innovation, improving markets and creating competitive opportunities.

Finding like minded people on the Web or on the Internet is rather easy. There are even many of the new kind of social network services helping with this task. Mostly, researchers know their colleagues in academia and have even a good overview of current industrial development. But talking to people alone is not sufficient to start working together. Standardization gives a platform for joint development of technologies. It has well established rules and processes that enable people to work together in a inspiring and balanced environment. If projects want to create such an environment it will take them too much effort and time thus increasing the standardization gap.

One of the very important use cases for standardization is the large cooperation between multiple projects, even internationally. How to integrate other initiatives from other stakeholders and even other continents remains a big issue in current European research. Occasional contacts to other projects can be informal, but as soon as many projects want to work together -industry included-, the organization of such cooperation becomes difficult. It is not sufficient -as many believe- that one would just need a mailing-list and some web space. There is much more to it like dispute resoluton, cooperation tools and the establishment of basic rules for cooperation. Modern standardization organizations provide all of that. So instead of re-inventing the wheel for every project, SDOs may help organize the larger cooperation of a project if this is needed.

EU IST Projects normally organize themselves around a consortium agreement. The project takes a while to establish the cooperation tools. SDOs do exactly the same. The rules for internal cooperation and decision making are normally called «Process». Working partly inside an SDO has the advantage of having an established set of rules for cooperation. If a project wants to connect to an SDO it should already take into account the SDO's process while making the consortium agreement. Considerable burden and waste of time can evolve from frictions between the internal consortium agreement and the process of the SDO the project wants to influence. If the collaboration is smooth, a lot of synergies can be achieved.

Progressing your project’s deliverables through the standardization process can be a time-consuming process. Although there may be – depending on the nature of the input you intend to deliver, as well as on the type of standard you decide to pursue – ways to achieve your goals within 6-12 months, mostly standardisation processes will take longer and require between 1 and 3 years.

Your project will however have a limited lifespan and will most likely not be able to allocate resources to standards work beyond that lifespan. In order to safeguard ongoing standardization work from falling apart after the completion of your project contract, you will either have to:

• Ensure all your project’s standardization activities can be completed before your project finalizes its activities;
• Ensure one or several of your consortium partners are in a position to continue and complete the standardization work initiated by your project at their own cost;
• Build a constituency among relevant stakeholders that are willing to continue and complete the standardization work initiated by your project at their own cost.

For these reasons it is recommended to plan interfacing with standards organizations at the beginning of your project’s activities. Even though your deliverables will not be available yet, it will help you synchronize with relevant ongoing standardization processes, and start the process of building the consensus required in order to achieve the goals you are pursuing.

Postponing this interfacing until your standardization deliverables are completed – usually towards the end of your project – will delay the standardization process and increase the ‘standardization gap’ between the end of your project and the availability of standards resulting from it.

Especially for Web standards, some particularities apply: Do not expect to be able to come with a photo-ready specification and get a stamp. This never happened so far in W3C. It is much easier to connect to existing communities than it would be to create your own community backing up your innovative request in some area. Getting contacts to the relevant community via a W3C Working Group is rather easy. It is sufficient to start communicating with the Working Group via the public communication channels that they are supposed to have.

Most plannings that are made have to be adjusted. The same goes for standardization and development. Regularly, creating consensus around an idea will take longer than expected. Trouble is that at some point in time the project is over and can not support the standardization activities anymore. Already in an early stage, partners should therefore determine the partners with the highest interest in standardization. It will be those who benefit the most out of the take up of the innovative idea in a specification. With those partners, the project should determine an emergency plan in case the standardization is taking on beyond the lifetime of the research project.

Since the Internet revolution in the nineties, standardization has changed its face. There are new rules and new challenges. The installed base on the Web and on the Internet is so large that it takes more than one stakeholder to change things or to make things take off. At the same time, the border between «standardization» and industrial grouping is blurring. Some consortia do not even do specification development but e.g. care for a certain implementation.

Stakeholders try to go forum shopping to gain advantages for their own technology. This means that one technology may be seen in several specification developing organizations. This is due to competition behavior of industry players, but also du to competition between specification developing organizations (SDO). E.g. most traditional SDOs today have a committee around RFID. But only rarely, the effort is undertaken to make those different specifications with different scope and core solution work with each other. So to make a complex solution work, one has to do a lot of guesswork to glue different solutions together. In this context it is important to determine the leading SDO of one area. Whether an organization is leading can be determined by the level of take up of their technology and specifications in a specific area. For GRID, OGF and OASIS e.g. are still the first class venues. For some of the underlying protocols used, there is a split between W3C and OASIS. For the new challenge of metadata, the use of W3C's semantic web technologies is encouraged.

It is very important that a Project makes a list of all relevant standardization places in its area. Once this is done, the fora and organizations found have to be carefully scrutinized for relevance, neutrality, impact, speed etc.. It is equally important that the project partners evaluate the IPR policy of a certain forum and determine whether this is in line with their own consortium agreement.

A project that intends for project results to contribute to standards needs to view standardisation as a process that begins at the concept stage of a proposal, and continues throughout the entire life of the project, and often beyond. The mindset should be one of a programme that involves a sequence of actions to achieve a specific result, much like a research programme that passes through different phases starting with an initial concept and ultimately leads to development and dissemination of new technologies. There are several important project milestones within a project lifespan where standardisation should be considered:

Milestone 1:

Proposal preparation stage -It is important to identify and plan for contributions to standards when preparing the project proposal. Projects that start off at the proposal stage with a specific intention to create a new standard or modify an existing standard normally allocate a minimum of 6 person month's effort to the specific procedural tasks of standardisation. However, the average for these types of projects is 12 person month's effort, usually spread over 18 to 36 months of a project. This does not include the research work related to defining the standard, only managing the process of standardisation within appropriate standards bodies. Therefore, it is important to allocate sufficient resources during the proposal stage and to maintain those resources during contract negotiations with the European Commission.

Milestone 2:

Start of the project contract- At the start of the contract it's important that the responsibilities for standardisation be discussed amongst the partners. At least one partner should be identified to participate in the standards bodies where the project expects to eventually make a contribution. The reason for this early participation is that it will later be important that at least one partner is familiar with the procedures within the target standards bodies, has contacts with the member organisations, and is able to identify who are the members that are influential or set the pace for the decisions within the standards bodies.

Milestone 3:

Requirements defined- Research projects generally start with the specification of requirements and designs of the technologies that will be developed. These requirements can be the basis for a first check of whether the research results are aligned with the work within the standards body. On more than one occasion, projects have learned by presenting their requirements and expected results that some standards already exist that address part of the technologies being developed. Sharing requirements and expected results within the standards body is also an important step in building awareness and support for the contributions to standards that will eventually be developed by the project. It can also be beneficial to the project for obtaining additional requirements as the representatives within the standards bodies might come from a broader set of industries of types of organisations than the project partners.

Milestone 4:

Results available for submission to standards bodies - The milestone where the project partners feel comfortable submitting a specific proposal to a standards bodies varies depending on the technologies and their maturity. Sometimes it is earlier in the project while research and development is underway, other times it is later in the project after the project has completed some validation with pilots or demonstrators. The misconception that many projects have is that submissions to standards bodies need to be very complete or exhaustive. What is actually essential is that the core components of the submission are stable, clear and fully defendable in meeting specific needs, even if some surrounding elements are not yet finalised. The process of consensus will likely result in changes and additions from other members of the standards bodies, which can strengthen the submission and also benefit the project.

Milestone 5:

Project contract termination - This is an important milestone because often the timing of the standardisation process extends beyond the duration of the project. Therefore, as the European Commission project contract is approaching closure, it's important to identify how the standardisation process will continue. With some planning and foresight, the time and effort invested during the project towards standardisation will lead to the project work becoming an industry standard, and in so doing, deliver expected benefits and broader opportunities for exploitation by the project partners.

An underlying principle for the project is that when planning and actions for standardisation occur earlier within a project, the results lead to more effective use of project resources and greater likelihood of meeting project objectives for standardisation.

W3C produces successful specifications, but W3C is a complex standards body. It produces only few high value specifications. The scope is limited to the Web or the Semantic web. A good strategy is to connect to people that have already experience with W3C and help you understand the mechanics. The W3C Team is also there to help you understand what possibilities there are.

The easiest match is if a project or initiative can connect to existing work to influence it. Innovation in applied research sometimes needs just a small fix in a given specification. As long as this specification is under development, it is rather easy to drop thoughts. Many W3C Working Groups are public and even those reserved for Members only must have public communication channels to receive feedback and scrutiny from the world at large. Use those channels to connect to the community in your area. The Working Group will likely hear your suggestions and you may want to join that Working Group to influence further.

Even an integrated project alone is not big enough to trigger new work in W3C. If the area a project is working on is not yet dealt with in W3C and within the scope of W3C (mainly «The Web»), a new Working Group or Incubator Group must be created. In this case a project needs all partners being committed to make it happen. It is better to appear as many partners than it is to appear as one project. It makes the momentum behind a certain development more visible to potential partners and may generate their interest.

See the Membership FAQ for the exact details

This is talking about Patent Policy, copyright, re-use of data and the like.

On the one hand, standardization organizations can be of value to projects. But on the other hand, projects can also be of value for standardization.