OntologySummit2009: Perspectives from the Standards Community    (1TT5)

Lead Editor: HowardMason    (1TT6)

Purpose:    (1TTI)

Scope:    (1TTK)


Content:    (1TTM)

This section gives some fundamental reminders about standards. It is followed by contributed ideas and suggestions    (1VB0)

A standard is nothing more than an agreement across a particular community of interest, to achieve mutual benefit, based on the best available knowledge and technology. Implementation is voluntary, unless mandated by legal or commercial constraints.    (1VB1)

The following ideas or misunderstandings have been contributed    (1VAL)

Many objects end up being identified multiple times in different standards. For example, units of measure are given different identities in various standards, and there are known to be two initiatives to give URI identifiers to them currently in progress. What is really needed is that the authoritative source (in this case the BIPM or ISO TC12) that should provide the URIs for all to just use.    (1TU9)

Many standards include rules, e.g. conformance classes that determine whether an implementation is conformant. In natural language it is always difficult to avoid ambiguity. This can be reduced by stating the the rules in logical form.    (1TT7)

The traditional approach to standardisation has been to replace native file formats with standard ones. This approach is not always the best one, because native file formats can be more concise and efficient and can have features which are not yet within the scope of standardization.    (1V7C)

In engineering analysis, system vendors define very effective formats for representing fields using meshes. Often there is little benefit in defining an equivalent standard format. However, within a standard file format there is precise meta-data about what the field is, i.e. the variable, the coordinate system, the units of measure, the region within which it exists, and the state for which it exists.    (1V7D)

Some of this meta-data may be contained within a native file format, but it is often incomplete. Also whereas a representation of a field is accessed by very few systems, perhaps only the system that created it, the meta-data is accessed by very many.    (1V7J)

A simulation data management system may be concerned with information about a field such as:    (1V7K)

* what it is (e.g. a pressure load over a surface);    (1V7M)

* the state in which it exists, and properties of the state (e.g. level flight at 1000 kph);    (1V7N)

* the region within which it exists (e.g. top surface of the wing).    (1V7O)

A simulation data management system may reference a native file that provides a description of the field, and specify the activity that created the description (e.g. an analysis or wind tunnel test).    (1V7P)

This approach requires standard engineering analysis meta-data which can be used along side native file formats. Standards such as ISO 10303-104 "Finite element analysis" have defined many of the meta-data concepts, but the current standards only allow these concepts to be used within a standard file format. An ontology derived from ISO 10303-104 would enable these concepts to be used to provide information about files in a native format.    (1V7Q)

Alongside an ontology of standard concepts, an ontology of analysis file types is also require so that the format of a native file, which is used to provide a description of a field, can be stated unambiguously.    (1V7U)

The NAFEMS CAD-FE Working Group intends to:    (1V81)

* develop an ontology for engineering analysis derived from ISO 10303-104 and other parts of ISO 10303, in order to specify meta-data for files in native format; and    (1V82)

* maintain a registry of analysis file types and analysis code versions in order to specify the format and provenance of a file in native format.    (1V83)

 This page is maintained by HowardMason ... please contact him if there is any question.    (1TT8)