IFRA

The following interview was published in the IPTC Mirror, issue 153.
The full issue can be downloaded here from the IPTC website.

Early in 2008, the first of IPTC’s G2-Standards were published — NewsMLG2 and EventsML-G2. By the end of 2008, Deutsche Presse-Agentur (dpa), an independent German press agency, had implemented the EventsML-G2 standard for its customers. Robert Schmidt-Nia, head of application development for dpa mediatechnology in Hamburg, spoke with the IPTC Mirror about how the implementation project began, the business case that supports it, the challenges that were resolved and the response of dpa customers. Here is what he told the Mirror.

You said that initially, there was no urgent need for you to implement EventsML-G2.

That’s right. We began thinking about adopting EventsML-G2 in 2008, as the model and ideas behind G2 became clearer and the standard stabilized. However, as a news
agency that provides major services using the IPTC 7901 standard, we did not face any direct market pressures to implement the EventsML-G2 at the time.

You said that initially, there was no urgent need for you to implement EventsML-G2.

That’s right. We began thinking about adopting EventsML-G2 in 2008, as the model and ideas behind G2 became clearer and the standard stabilized. However, as a news agency that provides major services using the IPTC 7901 standard, we did not face any direct market pressures to implement the EventsML-G2 at the time.

But that changed?

Yes, and fairly soon. Our customers let us know, for the first time, that they not only wanted, they required us to provide daily planning events information in the human readable 7901 format they already received as well as in machine-readable XML. That gave dpa a demonstrable business need to move to EventsMLG2.

As you prepared for this move, did the nature of the events information you provided change?

Significantly. Initially the stated customer requirements were only for “what / where / when” information, but as we discussed the objectives of the G2 approach with them and described how it could benefit their internal workflow, their interest was stimulated. The business case grew, you could say, in an “appetite comes with eating” manner.

From the first, we decided that we would provide more information than we had been doing. Within our internal planning system, PLATO, we had already handled events as pieces of knowledge. We know a lot about the event itself, but there is also a lot of
secondary information that can be provided and used to plan upcoming coverage. This might be references to other kinds of knowledge, such as persons or organisations involved with the event. We decided to package all these extra bits of information
together and offer them to customers. The aggregated information about a
single event becomes a product itself, now, with a very short time to market.

What did it take to carry out the project? How did you approach it?

The technical challenges we faced on this project were immense. Fortunately, one of the major obstacles that usually exists when a new format enters the market — i.e.,
the displacement of a legacy format by a new one — was not the case for us, so that simplified things.

We already had a planning system that provided the information the market required up until then. In deciding to combine all this information into event-specific products, we had to understand the impact of the project on the editorial departments — both that of dpa and those of its customers. Even if a solution looks very simple from the technical point of view, the impact on other domains may be underestimated. There were consequences we had to discuss and resolve beforehand.

We talked to our customers and learned from their requirements. By the time we got to
the implementation stage, we not only had important customer insights, but our customers were more involved in a way that made the implementing part so much easier.

Did you learn any important lessons from your implementation of EventsML-G2?

One of the things we learned was the value of the G2 developers’decision to include something in the standard only if there was a clear business case for it. Each feature of the standards had to be justified on that basis; it couldn’t just be theoretical. This prevented over-engineering the standard. The G2-standards might be powerful and
seem complex, but every feature is there because the standard was designed by major news agencies for agencies. Because of this, I think the G2-Standards are likely to reach the same level of acceptance as the 7901 standard or the ANPA standard. It is
responsibly engineered.

At dpa we used to discuss “How can I convince a customer or partner to adopt the new G2-Standard, while existing standards are still working?” The best opportunity comes in when you provide a new product or meet a new set of requirements by using the G2 format. Customers become familiar with the new standards, as they use something like EventsML-G2, and can begin to see how this will improve their own processes and their ability to gather crosslinked multi-media information.

What advice would you give others who want to do the same thing?

The breakthrough for us came with presenting EventsMLG2 to our customers and discussing it with them. Events as self-contained products were not on the radar of agencies or clients at that time. Customers said they only wanted such information as “what/when/where”, but we showed them that many other things were possible with G2.

Throughout all the discussions about event management, one topic kept recurring: “The available event data are not enriched enough to provide a worthwhile service in such a complex form”. But here we can profit of the flexible approach of the G2 standard. As long as the sending and receiving system are processing G2 objects, you can start even with a small set of data. Then, if your event model expands, you can expand the information you provide without violating the format you’ve agreed on with your customers and partners. In other words: “Just start with what you have!”

Have you been able to quantify benefits yet; if not, what benefits do you expect to see?

There are three different areas we need to examine for benefits:

One is the product itself — the actual event information.
Our planning system was designed primarily for internal purposes, with daily planning
event information given to customers as a standard service. From the customer point of view the “product” we provided was an aggregation of the most important events for a specific period of time. Deciding what was “most important” was a decision we made, however. There was no attempt to customize the list to specific customers’ local needs.
When a single event, alone, became a product, the decision of whether an event is important or not shifted from the agency towards the client. The beginning of a sailing season may not be important info for most clients, for example; but if the customer is on the coast, sailing may be important. When agency sends out all event information,
not just a “top ten” list, then customers select what they want covered and whether the information will come from the national news feed or from a local reporter or sponsor or government official. This shift also changes the kinds of additional information required for an event. Discussing these issues with our customers gave us the opportunity to learn more about their specific needs.

Another is the internal system architecture.
We have to help our clients improve their business processes. One aspect of this is to provide additional information along with the intrinsic news. This has to be done without adding to either client or agency workloads and without causing any delay in information delivery. Considering an event-centric news production gives us the opportunity to gather a lot of information about an upcoming coverage in advance. A
massive amount of news is based on known events for which information is available in advance. If the added event information is gathered within the planning system, and if the client inherits all of it in machine-readable format, then the editor can focus only on his write-up. All the supporting metadata — the added information — is populated by the system. The feedback we are getting from client technical (IT) departments, about the response to all this from their editorial teams, is “it’s great” and “it’s amazing what can be done these days.”

Last is how well the understanding and usage of G2 is spreading.
To tackle the upcoming requirements of the media market, the agencies and their clients have to adopt modern techniques to provide multi-media and multi-channel information. Most of the standards in use are not appropriate. It takes time to change existing systems in order to handle more complex information. With the new G2 News Architecture Framework, the IPTC has developed a standard that is able to handle all these requirements. To convince colleagues, customers and partners to adopt this new standard, some proof of concept and - even better - a success story is beneficial. I believe providing events as a new product with EventsML gives us this story.