IDS ADI 15926 Template Methdology - POSC Caesar · Web viewThe word Template is itself overloaded with different intentions and usages in different contexts, so this section starts

© 2009 DNV. All rights reserved.

ISO-15926 Methodology Specification forDATASET TEMPLATE CHARACTERIZATION

http://ids-adi.org

POSC Caesar – FIATECHIntelligent Data Sets - Accelerating Deployment of ISO15926

Realizing Open Information Interoperability

Rev Date Description Author CheckDraft 1 20th Mar’06 IDS Task 120 First Draft ISGDraft 3 19th May’06 Draft for initial IDS team review ISGV1 19th Sep’06 Published for extended IDS and ADI team reviews ISGV2 15th Mar’07 Incorporating IDS-ADI Team Input ISGV3-#Draft5

17th Nov’08 IDS-ADI workshop updates from New Orleans (Apr’08), London (Aug’08) & Boston (Oct’08)

ISG

V3 20th Dec’08 Deliverable from DNV to FIATECH as Informative Annex to ISO15926 Part 7

ISG MVS

V4 2nd Feb’09 Update incorporating feedback from FIATECH Camelot and IDS2 projects. Intended to support ISO publication of Part 7.

ISG MVS

DataSet Template Characterization – V4 – February 2009 Page 1 of 18

http://ids-adi.org/


Executive Summary

ISO-15926 is the standard for lifecycle integration and interoperability, based on highly generic information modeling principles, and with a high dependency on shared reference data. Whilst it

supports many valid and flexible implementation possibilities, these may not support the full lifecycle capabilities intended by the standard. And, being highly generic and flexible, achieving

comprehensive and consistent interpretation in different implementations is non-trivial.

ISO-15926-Part 7 Templates provide a means of standardizing these interpretations and implementations and provides an interface between the business subject matter expert domain and the generic modeling expert implementation domain. This “Template Characterization”

specification bridges these domains by defining templates in terminology applicable to both sides of that interface and by defining the methodology by which business domain subject matter

experts may characterize their data sets in terms of templates at the interface. The specification also defines as reference data those initial core templates required to support the methodology.

TABLE OF CONTENTS

1 SCOPE & RATIONALE.........................................................................................................31.1 Introduction......................................................................................................................31.2 Scope................................................................................................................................41.3 Rationale..........................................................................................................................6

2 DEFINITIONS........................................................................................................................72.1 Domains...........................................................................................................................72.2 Templates.........................................................................................................................7

2.2.1 The Template Compression Axis............................................................................82.2.2 The Template Lifecycle Semantic Axis..................................................................82.2.3 The Template Assembly Axis.................................................................................92.2.4 Subject Matter Axes..............................................................................................10

2.2.4.1 The Generic Typing Axis..................................................................................102.2.4.2 The Template Abstraction & Realization Axis.................................................10

2.2.5 Characterization Strength Axis..............................................................................112.2.6 Template RDL Level Axis.....................................................................................12

2.3 Industry Dataset Definitions..........................................................................................133 METHODOLOGY DESCRIPTION.....................................................................................15

3.1 Overview of the process................................................................................................153.1.1 Semantic Mapping of Well-Formed Source..........................................................153.1.2 Syntactic Mapping of Less-Than Well-Formed Source........................................16

3.2 Figure – Summary Mapping Flowchart.........................................................................164 APPENDIX A – Characterization Methodology – Systematic Procedure............................175 APPENDIX B - Worked Example........................................................................................18



1 SCOPE & RATIONALE

1.1 Introduction

This methodology defines and standardizes the process by which any industry or application dataset is mapped to, or characterized in terms of, ISO15926 Part 7 Templates. It defines the types of Templates required by this process and the logic by which they are selected and their signatures defined.

This document reflects business-best-practice in early-adopter implementations of ISO15926 and as such, provides guidance intended as an informative annex to Part 7. This document is therefore primarily intended for use by the business-domain subject-matter-expert (ie the “Domain Expert” understanding of doing and managing everyday engineering business in the capital facilities industries), involved in characterizing and mapping data. It is also required by the information modelling and implementation expert (ie the “Expert Modeller” knowledge of doing and managing information modeling for implementation in the information technologies and communications business); involved in developing applications and implementations generally. Those expert modellers involved in implementing explicit ISO15926 Part 2 representations should however focus primarily on ISO15926 Part 7 itself.

The language in this document necessarily includes terminology of both the domain expert and that of the expert modeller, and as a mapping methodology it is intended to bridge those two domains.

Disclaimer – Overloaded Words: Because of this cross-domain language problem, it is possible to read unintended meanings into what is said;

Not because any one domain has a monopoly on understanding; Not because any one domain has a monopoly on rigour and formality; Not because any one domain has a monopoly on business pragmatism;

But because both domains have different interests in information modelling, And because words in one domain are overloaded with baggage in the other.

It is not possible to invent baggage-free words for every concept in a natural language document. It is therefore essential: To recognize defined terms where they apply; To trust the intent and ignore the baggage wherever possible and; To ensure that understanding is achieved by collaborative application in practice.



1.2 Scope

The scope of the characterization and mapping process includes;

Element Characterization - analyzing the (syntactical) structure of the data elements and discovering the (semantic) meaning of each element – as such the mapping methodology may be thought of more as “characterization”. This is a process which requires primarily Domain Expert engineering business domain knowledge, (and physical data modelling knowledge only in so far as the original dataset may be already defined in a data model or data dictionary.) This characterization is therefore limited to lifecycle uses foreseen at any given time by those Domain Experts involved in this process;

Template Selection - mapping to ISO-15926 by selecting the most appropriate Part 7 Templates and parameters to express the content and meaning of the dataset and its elements characterized above. (Template types and those parameters that comprise their “Signature” are defined later in this document.) Those Templates and parameters available for selection are RDL-Items in the reference data library. (Note: RDL here includes all shared reference data, centrally managed and/or federated scopes – refer to definitions. Normal RDS/WIP processes apply to selecting and/or linking to existing RDL items and/or populating with new content);

Formality, Ambiguity and Evolution – The methodology defined here is intended to be sufficiently formal and rigorous that the characterizations and mappings generated are explicit and unambiguous in terms of the Templates and other RDL items selected. This cannot remove all ambiguity in the process of selecting those items, since this depends on Domain Expert interpretation of the intended semantics of the original dataset, and not necessarily the full lifecycle intent of ISO15926 itself. It is therefore part of the scope of this methodology that the characterizations become RDS/WIP content so that evolution to better (ie more lifecycle-capable) characterizations are manageable through RDS/WIP procedures and meta-data;

Identification – One consequence of rigorously defining the methodology by which arbitrary datasets are characterized in terms of the generic full-lifecycle ISO15926 approach, and how evolution of that characterization is manageable, is that many, many more implicit information components are discovered and made explicit, requiring explicit and rigorous identification (and management, versioning, etc.)

The scope of this characterization methodology currently excludes …

Rules - capturing rules, such as those for interpreting or validating content values. (This methodology makes reference only where such explicit and implicit rules may be discovered during the characterization process. Comprehensive rules are a requirement for lifecycle interoperability compliance, but the current scope excludes



any formal means for describing and capturing such rules.) Refer later.

Implementation Methods – Specifications for implementation of mapping, processing or Extract, Transform & Load software are not included, and no specific implementation technologies or languages are prescribed. (The example Excel implementation demonstrates how the concepts may be supported, and suggestsGUI formats for appropriate software tools. Note that GUI here includes any symbolic & graphical presentation formats beyond alpha-numeric text / XML.) Refer later.



1.3 Rationale

The rationale for this Characterization Methodology lies in the reasons for the existence of ISO15926 Part 7 Templates themselves. Even when seen as comprehensively complete, correct and consistent, the ISO-15926 Part 2 core model is highly flexible and generic, whilst the supporting RDS/WIP reference data library is extremely large and evolving. There is great scope for choice and interpretation of these resources, even by Expert Modellers. Templates and this Characterization Methodology exist in order;

To be the standard ISO15926 method of defining usage-patterns in the highly generic, underlying model;

To capture and standardized those usage-patterns as valid entity types of the Part 2 model, extended through specialization and assembly (and other relationship entity types) in RDS/WIP reference data;

To encapsulate the definition of such views, containers or documents that are involved in managed industry transactions, with associated business meta-data (identity, version, status and more);

To support user and API simplification layer(s) to hide underlying model complexity from industry use of these patterns and business configuration of these uses;

To provide a clear interface between the business and modelling domains to support work-breakdowns and distinct work-fronts for resources with different skill-sets.

To provide a systematic methodology usable by Domain Experts, on the business domain side of that interface, in order to characterize (map) their (arbitrary) external data and information in terms of those Templates and other reference data, and to identify the need for additional reference data to support those business needs.

To ensure that the products of that methodology are sufficiently well defined and unambiguously identified that they are manageable in the future lifecycle as business needs evolve and associated reference data is extended.



2 DEFINITIONS

This section defines those items on which are specifically required by this methodology.

{For definitions of other acronyms, abbreviations and other reference items involved in ISO15926 generally, please refer to Appendix xxx }.

2.1 Domains

There are two kinds of thing defined here, or in some sense the same things defined from the perspectives of two domains either side of an interface between them:

Templates … types and parts of Templates … in the Modelling Domain.Datasets … types and parts of Datasets … in the Business Domain.

Business Domain – The whole capital facilities industry engineering business knowledge domain in the widest sense. eg Everything in the FIATECH Roadmap except Element 9, within which Domain Experts have particular industry business knowledge on information usage. (See disclaimer on overloaded words).

Modelling Domain – The domain where the particular skills and expertise of the Expert Modellers concern the business of information modelling and in particular the implementation consequences of that modelling. eg the scope of FIATECH Element 9. (See disclaimer on overloaded words).

2.2 Templates

The word Template is itself overloaded with different intentions and usages in different contexts, so this section starts with some discussion of the issues behind the definitions. In order to define the different types of template involved, it is essential to recognize the business reasons for ISO15926 templates, described in the Rationale above.

In a formal logical sense, “A Template is a first-order logic predicate.”, and since this is a formal logical statement, it is also true in every other context, and therefore a necessary and valuable definition for the most generic implementation needs of Part 7. But, this is insufficient definition for the various types of template involved in the processes and tools for characterizing business data in ISO15926 terms.

Different types of Template are characterized along different mutually independent axes.



2.2.1 The Template Compression Axis

The first axis is the “compression axis” – the extent to which the Full-Part2 (aka Longhand) content of a Template is described explicitly in fully self-contained, verbose detail, as opposed to abbreviated, parameterized, referential and/or encoded with rules-based description, where the information content is no less explicit, no less unambiguous, simply expressed in compressed Short-Hand form. Transforming between Full-Part2 and Short-Hand form is known as Lifting (de-compression) and Lowering (compression). A Short-Hand form is valid if it can be lifted to valid Full-Part2 form and lowered again without any semantic losses.

Full-Part2 Template – a Template explicitly comprising Part 2 entities, previously / sometimes referred to as “Longhand Template”.

Short-Hand Template – a Template defined in terms of a “signature” from which the Full-Part2 form can be generated.

Signature – the ordered list of parameters (typed arguments) which define a Short-Hand Template.

2.2.2 The Template Lifecycle Semantic Axis

The second axis is the “lifecycle semantic axis” – the extent to which a Full-Lifecycle Template captures the full business lifecycle semantic intended by ISO15926, as opposed to a business Short-Cut Template which characterizes business semantics recognized as less comprehensive than the intended full-lifecycle.

(Note the ambiguity in “recognized” and “intended”. The Domain Expert may consciously recognize and intend that the Template used is a life-cycle short-cut for an immediate, but limited business purpose. Equally the Domain Expert may believe, even intend, that the Template selected is suitable for full lifecycle use, as intended by the standard, but simply not recognize a lifecycle limitation in the template selected. It is a management requirement that any Template selected may need to be replaced with another or others, sometime later in the lifecycle.)

Full-Lifecycle Template – a Template intended by the Domain Expert and agreed with the Modelling Expert as supporting the full foreseeable business lifecycle

Short-Cut Template – a Template recognized as supporting a limited aspect of the business lifecycle whilst otherwise satisfying this methodology.



2.2.3 The Template Assembly Axis

The third axis is the “assembly axis” – how larger Templates are assembled (by design intent) from or decomposed (by discovery) into smaller component Templates.

AT – Atomic Template - the smallest indivisible building blocks of the ISO-15926 model – the entities (things and relations) defined in that model. Smallest indivisible in the sense that further subdivision has no useful meaning in the business domain.

{Note - Generally AT’s are binary; that is comprising two identities connected by a specified role in a single relationship entity, but there are exceptions. Those Binary AT’s defining the usage of individual Part 2 relationships, are equivalent to “Proto-Templates” in Part 7.}

MT – Molecular Template - an assembly of AT’s and/or other MT’s that is considered useful in the business domain.

{Note - The starting set of Short-Cut Template’s are generally “Molecular” in this sense. Typically MT’s may represent a single “cell” or “field” in a dataset.}

{Note – it may be valuable that further classifications of MT’s are also standardized, larger re-usable sub-assembles, representing common sections of DT’s, but logically, since MT’s may be assembled from other MT’s, there is no significance to this methodology specification in defining such DT-sub-assembly-MT’s}

DT – (Document or) Dataset Template – larger MT’s (assemblies of multiple MT’s) that represent the characterization of whole datasets or documents involved in business transactions, or contractually significant exchanges at business interfaces.

OIM - Object Information Model – Not defined here.

{Note – all templates represent part of the information model of any object of interest in the business domain. The larger the assembly of templates the more of that object information model structure is represented. The superset of all possible assemblies, over all possible lifecycles, is the “whole” OIM for that object. If such an OIM can be pre-defined before any template characterization occurs, then the templates themselves can be standardized against it. If not, the OIM can emerge and evolve as the net result of all templates standardized so far according to the characterization methodology. This remains a question of what can be achieved in practice in projects creating template reference data content, and in managing lifecycle meta-data of their temporal parts, but does not change the logic of the methodology defined here.}

{Note - The issue arises with classes generally, intended by Part 2 as timeless entities over all possible lifecycles. In practice the methodology allows for lifecycle meta-data to be associated with temporal parts of any entities including classes.}



2.2.4 Subject Matter Axes

There are two dimensions to these axes. These are a generic type of the subject matter from a primary business domain perspective, and a level of abstraction or realization of that subject matter in the business lifecycle. The subject matter almost invariably involves multiple objects of different types, each with independent lifecycles requiring their own identity and management.

2.2.4.1 The Generic Typing Axis

Firstly before establishing the level of realization, it is necessary to recognize the Generic Type (GNT) of object we are dealing with from the primary business perspective.

Note : This is a very coarse high-level business classification of object type, not a substitute for the eventual 15926 entity type that will be discovered by the template characterization process. If fact it is necessary that this typing approaches the top-down 15926 taxonomy “sideways”, from the primary perspective of the business domain and not from the generic modelling perspective otherwise the selection logic simply mirrors the Part 2 model itself. Following this approach ensures that the mapping logic (and examples) leads domain experts to the correct template selection.

GNT (PH) - Physical (Physical and/or Functional) Business Resource(s) – Any physical, spatial or functional, facility(ies), plant(s), equipment or materials, whether fixed or mobile, consumable or processed, natural or artefactual, and any level of assembly of these. (Existent / continuant spatio-temporally)

GNT (PR) - Business Process(es) – Any business processes, activities, events (including the industrial processes themselves, if the business is a process industry). (Happening / occurring spatio-temporally)

GNT (OR) - Business Organization(s) & People – Any organization(s) or organizational units and/or people and their organizational roles, and any arrangement or level of assembly of these.

GNT (IS) - Business Information & System(s) – Any information or information systems representing any of the above.

2.2.4.2 The Template Abstraction & Realization Axis

The fourth axis concerns abstraction & realization on the “level of realization axis” (LOR) – strictly speaking, the extent to which the Template instance, its contents and the entities represented are individuals, classes or classes-of-class, and whether important relationships between these are classifications or specializations, but these are notoriously difficult



concepts to relate reliably to tangible business information. In general the Domain Expert would recognize the need for fewer classes and few if any classes-of-class than would the Expert Modeller.

It is however necessary that correct and distinct object types are recognized if business applications are to successfully manage the separate lifecycles of these distinct objects and types. This methodology, and the Templates and their selection logic, therefore use the following simplification, based on common industry best practice (See also IEC-61346-4).

LOR (T) – where the subject matter records the definition of an individual functional process location or role, or any level of assembly of these within breakdown structures or schematic topologies. Eg typically a role in any business or plant process, typically identified by a Tag for any role or unit of operation and its functional definition, but only in terms of those process(s) that provide the purpose of the identified role(s).The level of least physical realization. (Equivalent to IEC “FR”)

LOR (R) – where the subject matter is consolidated business Requirements including the functional purpose LOR(T) above, other functional cases and other capabilities, and any level of assembly of these. All the business requirements for any individual that might fulfill that role; typically Availability, Longevity, Operability, Compatibility, Maintainability, Safety, Reliability, Accessibility, Transportability, Constructability, Testability … any “ability” with business value in offsetting cost and risk, over and above the primary function or purpose.A level of lesser physical realization. (Equivalent to IEC “CS”)

{Note that such LOR(R) requirements often contain selection of available products and standardized resources, but they are not the definition of those available resources and standards. See LOR(P) below.}

LOR (P) – where the subject matter concerns an available Product specification, typically catalogue items, manufacturing and material standards, and any resource that might be “offered” as being available to fulfill a business need or role.A level of greater physical realization. (Equivalent to IEC “PS”)

LOR (E) – a where the subject matter records an individual resource employed / employable installed / installable to fulfill a business need or role for some part of its life. (eg Typically an Equipment item and the individual log or record of that physically realized item.)The level of greatest physical realization. (Equivalent to IEC “IL”)

2.2.5 Characterization Strength Axis



Mapping / Characterization is a process from looser to tighter definition. As the subject matter is characterized the template definitions selected progressively tighten from broader, coarser and weaker characterization to more fine-grained, narrower, stronger characterization. During the characterization process, (ie before the process is complete) the characterization involves templates that are weaker or stronger in this respect.

A Public Template – is a template that is exposed to domain experts and yellow-belt modelers during the characterization and selection process. They are either weak or strong.

A Weak Public Template (UWT) – is a public template selectable during the characterization process, but which needs further steps of selection and/or specialization of public templates before its signature is strong enough to map directly to a private template.

A Strong Public Template (UST) – is a public template whose signature maps unambiguously 1:1 to a private template.

A Private Template (SVT) – is a template described and implemented in explicit Part7 / Part 2 form, intended for use by implementors and black-belt modelers, but which is not intended to be exposed to domain experts and yellow-belt modelers.

2.2.6 Template RDL Level Axis

Another axis is the “RDL level axis” – whether the Template is standardized as initial / starting, core, standard or proprietary public reference data.

(Notice that almost all data can be seen as reference data at some level – data instances created by one party to be accessible by one or more other parties. No-one wants write-only memory.) So, when talking about reference data it is necessary to be clear about wide and narrow definitions of the term, and the flexible non-exclusive range of business arrangements possible between organizations which are primarily providers of reference data and those enterprises that are primarily users of reference data in those arrangements.

In general in this document, references to RDL or RDS/WIP are intended to cover this wide range of possibilities of public and private management of “shared” reference data for public or private enterprises and projects with centrally managed and/or federated arrangements.

The following definitions in line with Part 1, Part 4 and other parts of ISO15926 apply to Templates as RDL-Items themselves.

Base Template – a Template which uses Part 2 Entity-types only, no specializations.(Note some of these may therefore be abstract and that this is independent of whether Atomic or Molecular Templates.)



Core Template – a Template which is a “useful” standardized specialization / “variant” of a Base Template, which use Core RDL specializations in their signature and which are not otherwise standard or proprietary.

Standard Template – a Template whose signatures involve RDL content representing published content of other standards bodies.

Proprietary Template – a Template whose signatures involve RDL content representing proprietary content of other enterprises. (NB proprietary copyright content, independent of licensing or rights to use.)

Initial / Starting Set Template - simply signifies a historical level of agreement as a snapshot of RDL Template content, from which other Template content may evolve.

2.3 Industry Dataset Definitions

Datasets are characterized here on one principle axis, the assembly axis, the extent to which sets are assembled (or composed) from component parts, with cardinality and optionality of those assembly relationships. (Note - those assembly relationships may carry other attributes and roles in other relationships, but they are all nevertheless assembly relationships.)

Dataset – Any arbitrary set of data with a recognizable, identifiable business use or purpose. Any set of data which represents the information content of any “document” or “view” (or part thereof) involved any business use or engineering application and any interface or exchange between these. A dataset is therefore defined based on business requirements as understood by a “Domain Expert” in that engineering / industrial / business / management domain. It may include information concerning different business objects (e.g., plant, project, organization, role, function, piece of equipment … ) and be involved in different business processes (e.g., management, process engineering, design, procurement …)

Note on Representation – no form of symbolic representation is excluded here - alpha-numeric text, graphical or other symbolic forms - from literally documents and drawings in any traditional sense, to files, tables, views, queries, entities, relationships, properties, represented in any modelling style with any level of normalization in the existing business application.

Note on Schemas - no particular schema or style of modelling is assumed in this arbitrary dataset definition, but that this could therefore also include a dataset already modelled or partly modelled using ISO15926. In practice a view of the source dataset as hierarchically nested Document Object Model (DOM) is sufficient for use of the methodology.

Note on Information Content – As will become apparent in the syntactical and semantic characterization sections of this methodology specification, information content is also implicit in the organization of information in a Dataset, as well as the explicit data contents. (The distinction between content and presentation in the orginal representation or modelling of the Dataset may or may not be explicit



anyway, however the original Dataset modelling definition is a valuable resource to this characterization methodology.)

Note on Datasheets - The original focus of IDS was “datasheets” – that is Datasets that have recurring use in key engineering work processes, and historically where existing business or industrial use and standardization has resulted in “pro-forma documents”, either single record – one object per sheet (eg an API pump datasheet, an ISA instrument datasheet, a Process Datasheet) or multi-record (eg equipment list, line list, cable schedule, etc). (There is nothing in the definition of a “datasheet” that makes it distinct from any other Dataset so far as this characterization methodology is concerned, other than that datasheets are often used as examples to illustrate the process.)

Dataset Element - Any component part of a dataset, that is any identifiable sub-set of the Dataset, from which the dataset is assembled, for any reasons of standardization, efficiency, re-use or management. Datasets comprise Dataset Elements. Dataset Elements include sections, sub-sections, sub-assemblies and data fields or cells as defined below.

Dataset Cell - A cell is a smallest indivisible Dataset Element or data field in a dataset. Typically it may be an attribute “name & value pair” with or without units, but in fact includes any text, numeric or other symbolic content. A cell is “indivisible” only in the sense that it is the most granular representation identified addressably in the source or target dataset. (Note - The Cell may in fact contain implicit or explicit internal structure or external relationships that may be exploited by the 15926 characterization process.)

Dataset Section - A section is any Dataset Element which is an assembly of other Sections or Cells within the dataset. Note - These assemblies may be nested to any depth as parent / child, sections / sub-sections, and may be present in well structured hierarchical forms in the dataset (as in the well-formed example below), or may simply be implicit in the layout of more arbitrary dataset representation formats.

Dataset Record – A Section which represents a row (or column) within another Dataset or Section. That is a child-section whose definition is re-used n-times within the same parent-section. Typically the rows in multi-record documents like engineering lists and schedules, or rows or columns defining process cases, nozzles or other multiple parts within otherwise single-record datasheets or dataset sections.

{Note – not to be confused with the general concept of “record” as a recorded instance in a physical implementation – eg a database record.}



3 METHODOLOGY DESCRIPTION

3.1 Overview of the process

The systematic methodology, the templates, their signature definitions and a worked example are captured in Appendices A, B and C and summarized in Figure 3.2 below.

This section is intended to describe the methodology and inform the user in general terms of the mapping and modelling issues addressed, and the reasons for some of the unavoidable complexity.

There are two cases (and a third hybrid case) from which the mapping and characterization process starts. The arbitrary external data set subject to the mapping may or may not be well-formed (or be well-formed only in part). And, however well-formed there is always a human element to the mapping and characterization process by the Domain Expert.

The methodology covers both cases introduced above and as a result involves a two stage process. These two stages are described in 3.1.1 and 3.1.2 and the overall methodology is summarized in Figure 3.2 below.

3.1.1 Semantic Mapping of Well-Formed Source

In the well-formed case a full formal definition of the dataset is available from an existing implementation or application domain. Such definition may exist as logical and physical schemas, data dictionaries, view definitions as well as various data integrity constraints, encoded validation rules and so on. This definition will vary in sophistication and complexity depending on the application domain and the implementation, and that will affect how the definition is presented to the Domain Expert.

(The minimum syntactical form presumed by the Methodology is that each significant Dataset Element is unambiguously “addressable”, and a simple “Document Object Model” of views and deliverables from the application or business domain may provide sufficiently well-formed definition. See Syntactical Mapping below.)

In this case, the task is to semantically map these explicit Dataset Elements of the dataset definition to ISO15926, by selection of appropriate Templates and RDL-Items. Even in this well-formed case, the mapping and selection process will identify and make explicit additional data elements that do not exist, or are only implicit, in the original definition, and the process always requires example instances of views and deliverables generated by users of the application or implementation.



3.1.2 Syntactic Mapping of Less-Than Well-Formed Source

Commonly however, the starting point for the mapping process will not be sufficiently well-formed or necessarily have distinct definitions of the dataset schema, its validation rules or its presentation aspects. In fact, the Domain Experts may even have their Dataset wholly or partly defined as pro-forma document forms with examples of completed document instances, sometimes with documented procedures or work-practices defining their use.

In this case therefore mapping process has to start with the process of creating a sufficiently “addressable” syntactic form representing the significant data elements in the source before the semantic mapping process in 3.1.1 can be performed. A simple “Document Object Model” of views and deliverables from the application or business domain provides a sufficiently well-formed definition for the subsequent semantic mapping stage. Note that even creating this addressable form requires semantic interpretation by the Domain Expert of which are the significant Dataset Elements.

3.2 Figure – Summary Mapping Flowchart

Note … Syntactical ; concerning Structure & Addressability,Semantic ; concerning Meaning


Semantic Characterization Stage

Interact with RDL / WIPPropose New RDL Items

Syntactical Definition Stage

No

Use Current Map Version forIntended Business Use

Recycle from Start (as necessary)

Yes

(Optional) cardinalities,

rules, etc.

Starting Resources(Well-formed Domain

Schema & Dataset View)

Starting Resources(Pro-forma Dataset

View & sample instances

Excel or XML

(Addr. DOM)

Fig 3.2 Summary Mapping Flowchart

START

END

Pro-Forma (Excel) Template Mapping

Definition & Exchange File.

Part-8&9 OWL / Façade Representation & Implementation

?

View or Report Def

CreateDef

Each “Cell”Simple DOMAddressable

(Excel or XML)

?

?

No

No

Mapping LogicQ&A

?

No

Select Short-Hand Template(s)

Generate Full-Part-7 Templates

Select RDL Item(s)


4 APPENDIX A – Characterization Methodology– Systematic Procedure.

P7M_Characterization_Methodology.XLS contains the definition of the initial set of Public Templates and the initial set of Business Selection Logic

These worksheets define a systematic procedure for selecting these public templates and other RDL-Items that comprise their typed-argument signatures.

The worked example appearing as a worksheet in the above workbook uses the sample datasheet included in Appendix B below.



5 APPENDIX B - Worked Example


Documents

IDS ADI 15926 Template Methdology - POSC Caesar · Web viewThe word Template is itself overloaded with different intentions and usages in different contexts, so this section starts