Oil ITJ—What exactly is the deliverable from the catalogue? Starting with an Excel spreadsheet of ‘approved’ names of things – what do you do next?
Camden—Our deployment technology (now resold by Landmarks Graphics) sits over existing information source systems. Source systems are used ‘as-is’. The Catalogue holds metadata that describes the individual entries in the underlying systems together with a link that can access those entries. For a document system you would link to the metadata in the DMS and hold this in the Catalogue together with the document ID. Likewise for a database you hold metadata about the item (say a well header in OpenWorks) and the item’s ID in the database.
Doniger—We can think of a catalogue in the sense we are defining as an adjunct to a federated system of data sources. Rather than simply bolting a common portal over multiple data sources, the catalogue idea calls for a thin and consistent characterization of the populated ‘items’ in the data sources that can be useful for qualified queries.
Oil ITJ—One can see how all new data capture software should use the catalogue in drop down lists etc. But do you integrate a new catalogue into legacy systems?
Camden—The whole point of the Catalogue is to bring together information from existing systems. Normally the Catalogue holds nothing but metadata—all the source systems stay as they are.
Doniger—I think of the catalogue concept as an analogue to a (book) library catalogue system, which in my youth consisted of catalogue ‘cards’ for each ‘book’ organized by ‘title’, ‘author’, and ‘subject/keyword’. Physical books were identified and organized by a vocabulary-based classification system. Our catalogue concept is an electronic form of this practice augmented with additional catalogue attributes and, as Dave describes, with value-added access mechanisms to digital data and document data stores.
Oil ITJ—Do you have to wait until Landmark and Schlumberger have adapted all their database software?
Camden—No, but you do have to write adapters to provide the views from databases. We are working with Landmark, who already have a set of adapters for most of the commercial databases through its Team WorkSpace technology. We will use those adapters ‘under’ the Catalogue to provide ready-made connectivity. Connecting to existing document systems is similar but tends to be simpler.
Oil ITJ—The KID work comes from one or two companies—where the Catalogue is deeply engrained in all their tools. But what happens when this list meets another—perhaps less formal list in another company’s toolset? Is there any real hope of adoption of a common nomenclature—especially given local differences in terminology and usage?
Camden—We are not talking about low-level integration of the type that companies like Tibco are implementing or the kind of detail required for inter-application connectivity. When it comes to existing database models it is relatively easy to map from their low-level attributes to the Catalogue’s high level ones because they define things like data types very well. Problems can arise, usually with document systems, where the existing metadata is inadequate and so incapable of being used to properly populate the Catalogue.
Doniger—The goal of the POSC Cataloguing initiative and the associated evolving standards is to gradually develop common vocabularies—at least as Dave says at the large grained, high level portions of the classification vocabularies—so that the need for and complexity of mappings is reduced.
Oil ITJ—How does the Flare technology actually work?
Camden—We have a web-served system based on Lotus Notes. We either serve the Catalogue remotely or have a server at the client site. The Catalogue is essentially a set of Notes databases with a lot of functionality built around them to provide users with a ‘smart’ interface. This is necessary because the metadata model is quite complex and the users don't want to be exposed to it.
© Oil IT Journal - all rights reserved.