NORSOK SCCS ONTOBRAS-2013 The industrial application of ontology: Driven by a foundational ontology A ‘structural constraints’ case study t opics Themes Background Expose the semantic structure of the data Make the meaning/semantics of the hierarchy explicit Expose the dimensions/facets 2 Themes Themes Remove constraints Background Data Foundation (DF) Initiative Data Foundation Initiative We are developing a common data foundation that can support all technical projects ( including exploration) and production operations The data foundation is aimed to act as a master data model that can be used to bring together various ‘islands of transactional data’ in all operator’s applications for project controls (e.g. P6 and cost management) and finance (e.g. SUN or SAP) The data foundation model is to be activity engineered as a semantically accurate representation of the business reality for all phases of the hydrocarbon lifecycle . A data source Z-014 Standard cost coding system (SCCS) (Rev. 1, Oct. 2002) This NORSOK standard describes a system for coding of cost and weight estimates and as-built/experience data. The system comprises 3 sets of complementary sub-coding systems named: PBS (Physical Breakdown Structure) SAB (Standard Activity Breakdown) COR (Code Of Resources) http://www.standard.no/en/Sectors/Petroleum/NORSOK-Standard-Categories/Z-Stand-Cost-Coding/Z-014/ 7 The role of NORSOK Z-014 NORSOK Z-014 is to be used as the classification system for activity, asset structure and resources. Expose the semantic structure of the data Including the underlying relations Current form of PBS, SAB and COR The current NORSOK lists (PBS, SAB and COR) are unstructured or semi-structured data Structuring the lists The first stage, before we could work with the data, was to convert the lists into structured data Code Name Description style.visibility style.visibility Making the underlying structure explicit We regard the structure as important to our goals. One aspect of this is that we are now making the underlying semantic structure of the structured data explicit in our data foundation. This will enable us to manage the structure; rather than the structure managing us. It is also vital to our goal of integrating our current islands of transactional data . style.visibility style.visibility Make the meaning/semantics of the hierarchy explicit What is the meaning/semantics of the hierarchy? All three NORSOK sets are hierarchies technically tree hierarchies; where each node has only one parent. However, the meaning (semantics) of the hierarchy links is not clear. B Land based installations A Offshore field installations Should the hierarchy have a top object? AA Topsides AB Substructures AC Wells BA Utilities BB Offsite BC Site 0 Field Installations What is the semantics of this arrow? (and the other arrows?) Is a Site a type of Land based Installation or is it part of one? style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility Two intertwined hierarchies Our initial analysis reveals two types of links in the hierarchy that are intertwined Super-sub-type (Classification) where the super-type is more general than the sub-type E.g. the type ‘animals’ is more general than the type ‘mammals’ Whole-part (Composition) E.g. my hand is part of my arm Sample - Adding the semantics (1) We have started fleshing out the semantics – and the hierarchy Legend: SST – (Super-)Sub-Type W-P – (Whole-)Part Topsides are part of Offshore Field Installations, Wells are a type of and part of Offshore field installations Sample - Adding the semantics (2) Electrical power supply is a part of electrical power systems that is a type of Utility? Expose the dimensions/facets Expose the implicit dimensions/facets The hierarchy contains a lot of information in implicit dimensions/facets In some cases, a ‘tree’ structure hides some important nodes; for example, wells . We have come to the view that the tree structure is too inflexible to store these dimensions/facets Disciplines – an example implicit structure in the coding There is structure, but it is implicit. It is not computer readable. Current ‘tree’ structure hides some important nodes Current ‘tree’ hierarchy structure, squeezes some patterns into a flatter structure. These can be identified and make explicit B Land based installations A Offshore field installations AC Wells BF Onshore wells 1 Wells Wells appear in the current hierarchy in two places. No way, in the current hierarchy, to consolidate well across onshore and offshore. Make the single Well classification explicit More generally, can make the classifications common to onshore and offshore explicit style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility style.visibility Current ‘tree’ structure hides some important nodes The ‘tree’ structure hides some important nodes. For example, wells. We have come to the view that the tree structure is too inflexible to capture the hierarchy properly. We have relaxed the constraint on a single parent. Repeated patterns; Identifying candidates for facets Sorting by name enables some obvious potential candidates to be identified. Adopting a dimension/facet structure We are considering a dimension/facet classification structure. http://en.wikipedia.org/wiki/Faceted_classification Note: some dimensions span the three NORSOK lists. This has several advantages; Can ensure that the dimensions are consistently applied. Less data to maintain, as the dimensions are only defined once (instead of many times). Raises the possibility of a configured hierarchy – where a dimension is not applicable – it can be taken out globally. The original structure 25 An early draft … Lesson Identified: dimensions/facets A dimension/facet based hierarchy enables repeating patterns to be extracted and managed. Summary 28 Summary Simple exercise from an ontological perspective. However, it does reveal why refactoring is often needed. Clearly the constraints are rooted in a paper and ink mindset . Rational reconstruction; what would the structure look like if the designers used a top ontology? Reveals a different richer structure. 29 Questions 30
BORO Publications
NORSOK SCCS:
An improving ‘structural constraints’ case study
22 September 2013Presented at Tutorial - ONTOBRAS 2013, Brazilian Conference on Ontologies, 23-25 September 2013, Belo Horizonte, Brazil
Overview
This tutorial provides an illustrative example of how the BORO methodology has been used to re-engineer and improve ‘structural constraints’ in existing frameworks. It provides a nice example of how an ontological analysis can reveal the constraints and identify how they can be improved. The case study is taken from a project that developed a common data foundation for an oil and gas enterprise. One area under analysis was cost management. The starting point for the analysis was the NORSOK Z-014 Standard cost coding system. The tutorial looks at its the structural constraints were identified and remedied. This is part of a series of tutorials that walk through examples that illustrate how the BORO methodology has been used to re-engineer data in an industrial context.