While setting up my company fourteen years ago, I benefitted from a government-sponsored scheme that encouraged the unemployed (remember $10 oil?) to get off their butts and create their own businesses. As part of the process, heads of earlier startups that were still in business devoted some of their time to picking over business plans such as mine and offering free advice. This proved very valuable to me, but before I explain why, I am going to elaborate on what seems to be a growing tendency to give products or services, not so much a bad name, more of a dumb name. One that, in the interest of a perceived marketing benefit, actually provides potential buyers with a complete bum steer as to what is on offer.
Last month we reviewed a book titled ‘Discovering the Value of an Integrated Information Framework’ and described the book’s title as ‘obscure.’ In fact it was only our idle delving into the booklet—page five in fact, that it emerged that the book was about the now officially released IBM ‘Chem and Petro’ Framework (page 1). Since then, the obscure title has gone and IBM has released the RedBook with a more appropriate title, ‘Discovering the Business Value Patterns of Chemical and Petroleum Integrated Information Framework.’ Neither grammatical nor snappy—but at least it tells you what’s inside.
We encounter naming issues in everyday life as witnessed by the ubiquitous my-whatever. mySpace, My Yahoo, or as my son is currently working on, my CV. All such possessiveness is fine so long as it remains on your disk, or in your Face Space or whatever—but once emailed—my CV loses implicit ‘context.’ Is this my CV or your CV? An easy fix is to add a name—better still, your name and the company/job you are applying for. The name really needs to provide all the context—you never really know what ambiguities might arise in future use. Better still, nail all this down in the document properties before signing and sealing the whole thing as a pdf. Capture the context as metadata.
Which brings me to the interesting development chez Energistics which is launching a ‘use of metadata’ initiative this month (page 10). A laudable field of investigation for the oil and gas standards body—but I do have a comment to make on the nomenclature…
The ‘metadata’ tag has pretty well been hijacked by the geo community to the extent that ‘metadata’ to anyone who works anywhere near geographical information systems means ‘geographical metadata.’ As an ex geophysicist and having a more general interest in ‘data about data,’ I am in another camp that sees metadata as stuff that gives context to just about any information. I assumed that Energistics would be advancing a similarly broad church definition.
Having read through the Energistics literature, I’m not so sure. I read in the prospectus that ‘the initial focus is on structured and unstructured information resources that contain explicit spatial coordinates.’ So I conclude that we are talking about ‘spatial metadata.’ But later we have, ‘the intent is to develop a standard that can be expanded over time to support additional content types, place name locations, and other segments of the energy industry.’ The Roadmap also mentions Dublin Core—a rather horizontal metadata initiative that comes out of the document community.
And I am now puzzled. Are we going to work our way from ISO 19115 to a new metadata standard for seismic? The ambiguity in the initiative’s title may be designed to produce an open ended project. But going from GIS to production data and seismic is putting the cart before the horse. Again—it is all in a name—or not!
Curiously, if the top level folks play free and lose with the nomenclature, this is not so for the lowly computer programmer. In the old days of programming, i, j, k, were automatically assigned integer status by the compiler—leading to unexpected behavior and occasional havoc. Today, professional programmers use longwinded names that summarize what is being counted, how high you can count, and maybe a notion of the variable’s scope in the program. Context, context and context is to programming what location is to real estate!
Bad naming can be the result of an expensive marketing study that has gone wrong or a last minute author’s brain fart - what shall I call this editorial for instance?
When I asked for a review copy of the new book* ‘Viral Data in SOA*’ I imagined that this was viral as in ‘viral marketing’ i.e. a good thing. Not so. The book is about the risks of bad data to the enterprise. Seemingly these are heightened with the interconnectivity that SOA brings about. The book is actually about data quality (page 3). But the title, once unpicked, holds the subliminal message that a) SOA is widely deployed (is it really?) and b) somehow bad data gets worse in an SOA environment (how is that now?).
Now to get back to the advice I got on when starting my own company. I had decided to set up a consultancy to work in data management to the French oil and gas sector and had prepared the ground with a survey and business plan. But the original company name was something of a brain fart. In my business plan I called my company ‘Données-Moi!, a bad pun on the French for data (données) and the French for ‘give’ (donner). Perhaps an English equivalent might be ‘Data R Us.’ My advisor intimated that this silliness was in poor alignment with someone of my age and general seriousness! Good advice on two counts—the bad name and the fact, unknown to me then, that age had conferred seriousness on myself. Hey, fourteen years down the road I must be really serious now!
* Viral Data in SOA, An Enterprise Pandemic, by Neal Fishman, IBM Press/Pearson, ISBN 978-0-13-700180-4.
** Services-oriented architecture.
© Oil IT Journal - all rights reserved.