BACK to
Implemenation
Guidelines

Overview

Description

The Info Object Schema

The basic viewpoint taken by the NPDM is that there will be all kinds of additional information connected to aspects of the system/product data. Possible information types include:

• specification documents

• engineering and other drawings

• manuals for products, including support equipment, calibration tools, etc.

• maintenance manuals for major sub-systems

• EDIFact and email messages

In fact there will be such a variety that no attempt has been made to sort these types of information into pre-defined buckets. Instead the NPDM provides a kind of library facility for holding information and linking it to the detailed information covered by the rest of the model. Such links may be very general in nature, simply indicating some relevance of the document

The information object area of the data model is very general in that it can be used to support several different processes. Some of these are identified below by listing the input, controls, etc. An additional column identifies the suggested target for an information link from the resulting information object(s).

 

Figure 11.1 ICOM notation

 

	Input	Control	Mechanism	Output	Linked to
	Task and task method, resources, etc.	AECMA 1000D spec	Technical writer (person)	One information object containing the Data Module according to 1000D DTD	Task method assignment, Product
	Task and task method, resources, etc.	Various (could be AECMA or in-house defined format)	Query and report function	Two information objects, one containing the task description and one containing the parameters/instructions for the query/report.	Task method assignment, Product
	Task and task method, resources, etc.	Various (could be AECMA or in-house defined format)	Query and report function	One information object, one containing the parameters/instructions for the query/report.	Task method assignment, Product
	Many tasks and associated data	Various (could be AECMA or in-house defined format)	Technical editors and/or report generators	Publication collection equivalent to a maintenance manual

 

These can be described as follows:

(1) This is the current traditional process of giving a technical writer access to the LSAR to produce a data module. The NPDM lets the resulting SGML be stored in the same database and potentially linked to the task description in the database.

(2) The database is queried to produce a report which is the task description. Both the resulting task description and the query are stored in the database. In the case of the query, this allows the report to be updated as and when necessary.

(3) In this case the query only is held in the database and it is invoked when necessary. This will support the use of the database as the source for an IETM.

(4) A collection of task descriptions is published together as a maintenance manual.

This part of the NPDM is fundamentally simple but does not seem so because it contains a lot of recursive relationships. Hence, to help understand what this part of the NPDM supports, consider the following analogy:

• We have a collection of specialist papers (in electronic form) and a database which deals with the same area.

• The database includes a list of the papers and some key links from the list to the corresponding data.

• It also contains references to papers held in other collections.

• New papers are created which are based on queries against the database and also on the existing papers and even the external references.

• If a particular new paper is considered useful or valuable or is to be made available externally, it is added to the collection of papers.

• Occasionally an expert in the topic publishes either a single paper or a collection of papers together. Extra information (such as the date of publication) is held in the database for such publications.

This is roughly how the information object part of the model is structured:

• Each paper, whether old or new, is an information object. New papers are added firstly as information objects.

• In the case where a new paper is the result of a query against the existing data, it is marked as such (this is a derived information object).

• The query itself is also stored (as an information object derivation). It is possible that the query is more useful than the resulting paper and so only the query is kept (so it can be re-executed on demand).

• A paper which is not held in the local database is also held as an information object too. However it has an external reference as content (using the curiously named document entity).

• The links from the papers back to the database are held using the information link entity.

• Published papers are held using the publication collection entity which allows the date of release and other similar information to be held.