Q & A

6. "How can we distinguish engineering data from meta-data?

The engineering data is that referenced by the 'data_item' attribute of the 'managed_data_item' entity. The 'meta-data' is everything else associated with the 'managed_data_item' and its parent 'managed_data_set'. Basic CIS Translators will not deal with meta-data and will therefore not deal with these two entities. There are some cases where the meta-data is also used as 'engineering' data - e.g. date_and_time, person_and_organization.

(See also slide 31)

7. "Is there a built-in means for extending CIS/2 entity definitions?"

If the definition of an entity in the CIS/2 documentation is unclear, the authors should be consulted. The best way to do this is via the CIS Users Group, or the CIS/2 web site.

Users may not define new entities. Nor may they define new attributes for any of the entities. There are no 'user defined types' in the CIS.

8. "What if people wish to extend scope of LPM/5?"

The current LPM/5 schema (available from this site) should be considered a beta version. We are still open to comments on it, and the rest of the CIS/2 documentation. The formal SCI publication is due for launch in July 1999. At that time, the LPM/5 schema will be fixed - any changes that are deemed necessary will have to go through the user group and put into a new schema (LPM/5.1) and released with a new CIS/2.1. These releases are likely to occur only once a year at most. More importantly, they will be upwardly compatible.

9. "How can additions be made to LPM/5?"

Once the LPM/5 schema is fixed in July 1999 - it will not be possible to make additions to LPM/5. We then look to the next release of the CIS (say CIS/2.1 containing LPM/5.1) or even the next generation of the CIS (say CIS/3 containing LPM/6) depending on the additional functionality requested. There are several constructs in the LPM that appear highly complex, but they do allow for future extensions through subtyping.

Currently, the SCI is acting as the custodians of the CIS. It is doing this on behalf of the CIS Users Group and the wider industry. If this situation continues, then if people wish to have the LPM extended, they should propose this via the CIS Users Group (or through the web site). The web site will also host an 'Issues List', to which users and software vendors will be asked to contribute.

10. "What about using XML as an implementation tool for CIS/2"

Traditionally, STEP has focused on the use of standardised exchange files for communicating information. However, many in the STEP community are investigating mechanisms for more dynamic and finer-grained information sharing using database management systems (DBMSs). Within STEP, the different types of data sharing are referred to as levels of implementation. These are:

Level 1 data sharing by means of exchange files.

Level 2 data sharing using a standard in-memory data format.

Level 3 data sharing using a database management system as the means of data storage and access.

Level 4 data storage and access via a knowledge-base system.

When implementing a ‘Basic CIS Translator’, vendors need to satisfy the requirements of a Level 1 STEP implementation. When implementing a ‘Product Model Repository’ or a ‘PMR-enabled Translator’, vendors need to satisfy the requirements of a Level 3 STEP implementation.

It should be noted that the ‘implementation forms’ above are the forms that have been identified within the STEP community and are not the only possible forms of implementation. Researchers are currently investigating the possibility of combining the technology of STEP – which is primarily concerned with the representation of data – with the technology of the World Wide Web – which is primarily concerned with the presentation of data. It is likely that XML (eXtensible Markup Language) will become an accepted alternative to STEP Part 21 as an implementation form of an EXPRESS schema.

See The ST-Developer On-line Manual and the New Work Item "XML representation for EXPRESS-driven data" and the notes by Daniel Rivers-Moore on the NIST web server.

11. "What is a comparison between these two toolkits incorporated in this agenda?"

The EDM toolkit was not shown in its best light at the AISC CIS Workshop.

I have used several different toolkits over the past 6 years, including ST-Developer, EDM and ProSTEP. The latest versions of these toolkits show vast improvements of the previous ones. Any of these three are suitable for the job of CIS implementation. There are also several public domain toolkits available (e.g. Expresso from NIST) - but support for commercial implementation is (understandably) limited. It has been suggested that toolkit vendors could produce a cut down (and cut price) version of the toolkit that only worked with the LPM/5 schema. It would also help the CIS implementers if the toolkit came with the LPM/5 schema built-in (and pre-compiled).

On the subject of EXPRESS validation...

It is true that the original 1994 release of the ISO STEP Generic Resources contained many errors. Hopefully, we've caught most of these because we have parsed the LPM/5 schema using several toolkits, including EDM. Different toolkits pick up different errors. They also interpret the EXPRESS Language Reference manual differently. Some even pick up errors that aren't really errors in EXPRESS, but may give problems on implementation. They also use different implementations of SDAI. Some are more efficient (particularly at memory management) than others.

In terms of validating STEP physical files, I would expect all commercial toolkits to be able to validate WHERE, UNIQUE, and INVERSE clauses. They should also be able to extract information from the DERIVE clauses, and check any FUNCTIONs and RULEs. These things are essential for commercial implementation of EXPRESS schemas.

12. "Can you get this same section/shape data from a ‘flavor’ file versus relying upon the convention included in CIS/2?"

The flavour (English spelling please!) file is merely a collection of identifiers or references for standardized items. The shape data (and all other data) is found elsewhere - e.g. in national standards or manufacturers catalogues. The use of the flavour file relies on the fact that both the sending and receiving applications have access to the shape data locally (e.g. in a native database). If this is not the case, then the data must be 'passed by attribute value' rather than being 'passed by reference'. The LPM allows the information to be passed by both attribute value and by reference. If both applications involved in the data exchange have fully populated native databases, then those databases may contain information that lies beyond the LPM. In general, the 'flavour file' is used to exchange information implicitly (via the reference) rather than explicitly (via the attribute values).

13. "How many nodes may the different surface elements contain?"

Surface elements may 'contain' (or rather - be defined by) any number of nodes. The minimum number is 3 for a plane triangular element. There is no upper limit defined in LPM/5.

14. "Is there an element or something defined that groups all items in LPM/5 associated with a particular entity?"

This is exactly what a Base Conformance Classes (Base-CCs) does for an entity (type). (See Q32.)

To group any entity instance with any other entity instance, use the grouping constructs.

15. "Focus upon analysis and design overlap – perhaps develop slides to explain the LPM/5 entities that will be more applicable regarding the exchange of 3D model data between analysis/design and detailing applications"

These will be included in the "Worked Examples" publication.

16. "How do you deal with compound sections – e.g. cruciform sections"

Using a section_profile_compound. (See diagram below.) This is a type of complex section profile that is as made up from two or more other section profiles. Each of these section profiles is placed with their local coordinate system related to some point. Each of the section profiles may also be rotated with respect to a reference coordinate system. In some cases, the local coordinate system of the first section profile referenced would provide the reference coordinate system to locate and rotate the remaining section profiles. Back-to-back angles and crane rails are simple examples of compound section profiles.

17. "In LPM/5, what is the number (e.g. WR41T1B)?"

It is merely a label for the WHERE rule. EXPRESS demands that the name of the WHERE rule be unique in an entity hierarchy. In LPM/5, they are unique throughout.

18. "When you talk about a planar assembly, does this mean we can describe, e.g., a pressure vessel or a tank?"

No. A planar assembly is one that lies in a plane i.e. one that is predominantly two dimensional- e.g. a floor slab or a wall. A pressure vessel is three dimensional and therefore is described using an assembly_design_structural_member_cubic.

19. "Can you provide an inheritance diagram for the Part 21 File homework assignment?"

Yes. These may be included in the "Worked Examples" publication - still in preparation.

20. "Is there a syntax checker for detecting incompatibilities within a Part 21 File?"

Yes - most STEP toolkit have one - some are better than others and are able to pick up errors that others can't.

21. "Distinguish between syntactical and semantic issues regarding development of Part 21 files"

There are no semantics to a Part 21 file - its just plain dumb data. A toolkit will be able to check that the Part 21 file conforms with the STEP Part 21 spec and the appropriate EXPRESS schema (LPM/5). It can also check WHERE rules etc. It cannot check whether the data makes any sense. That's down to the translator developer.

22. "There was no linear zero item in the Part 21 File assignment."

This has been corrected and reissued to the participants.

23. "Are there technical publications that we can refer to in order to learn the EXPRESS language?"

Yes. You can learn the basics from the CIS documentation. For more detailed information see "Information Modeling the EXPRESS Way", by Schenck, D. & Wilson, P.; available from Oxford University Press, Oxford, 1994.

24. "Could you please provide a very descriptive discussion of a ‘correct’ answer to the Part 21 File homework assignment?"

Example STEP files have been issued. Worked examples will be included in a future publication (in preparation).

25. "Would CIS/2 allow vendors to put out an assembly to define the boundaries of elements and then leave it at that?"

In the CIS, there are three ways of viewing structural engineering information (sometimes called three levels of abstraction): analysis, design, and manufacturing. In this context, 'elements' are analytical devices, whereas assemblies can be either design concepts (assembly_design) or manufacturing specifications (assembly_manufacturing). For design purposes, assemblies can be very abstract, with just a name, number and description. For analytical purposes, an analysis_model is composed of elements and nodes. If the SUPERTYPE entity 'element' is populated on its own (i.e. rather than as one of its subtypes) it merely has a name, number and description, and a relationship to its parent analysis_model. It also requires 'connecting nodes' - established via the 'element_node_connectivity' entity. Thus, it has no real shape (other than that derived from its connecting nodes) or any material (which is represented by the subtype 'element_with_material').

26. "Can you elaborate on exactly what meta data is and how you can use it?"

Put simply, meta-data is data about data. It is mostly artificial and created by the application.

CIS/2 provides data management functionality in the LPM by separating the data from the ‘meta-data’, and then allowing those applications that can associate the ‘meta-data’ with the data to be shared (i.e. DMC applications) to do so. This ‘meta-data’ includes some or all of the following:

The unique identifier for the item.
The version of the item.
The person who created the data.
The date when it was created.
Whether the data was new or old data that had been modified.
The date when it had been modified.
Whether the data has been approved or not.

In CIS/2, data management is considered to be the process of assigning meta-data to data. For example, a DMC-application would be used to assign a unique identifier to an instance of assembly and place it in a set that stated who created the instance, when it was created, and whether it had been modified.

In simple terms, ‘Data Management Conformant’ (DMC) applications produce ‘managed data’ such that each item of data is given a unique id and placed in a data set, while Non-DMC applications will produce ‘unmanaged data’. Furthermore, ‘unmanaged data’ may be mapped onto meta data to become ‘managed data’, using CIS/2.

Of concern to the writers of DMC-Translators are the two entities ‘managed_data_item’ and ‘managed_data_set’, which form the essential EXPRESS constructs in the LPM for data management by capturing the meta-data. A ‘managed_data_item’ represents an individual item of managed data and allows a data item to be assigned a unique identifier, a data set and a version. A ‘managed_data_set’ is simply a collection of managed data, which assigns the additional ‘meta-data’ that is associated with each and every item of data in the set.

Sample entity instances in data section of a STEP Part 21 physical file

#1 = GROUP (‘new data group’, ‘a new test data group’);

#2 = PERSON_AND_ORGANIZATION (#3, #4);

#3 = PERSON (‘NW556688’, ‘Smith’, ‘John’, $, ‘Dr’, $);

#4 = ORGANIZATION (‘SS3456’, ‘FABSTEEL’, ‘Steel Contractors Ltd’);

#5 = PERSON_AND_ORGANIZATION_ROLE (‘creating person’);

#6 = DATE_AND_TIME (#7, #8);

#7 = CALENDAR_DATE (1998, 30, 12);

#8 = LOCAL_TIME (14, 20, 30, #9);

#9 = COORDINATED_UNIVERSAL_TIME_OFFSET (0.0, $, .AHEAD.);

#10 = APPROVAL (#11, ‘no level’);

#11 = APPROVAL_STATUS (‘not approved’);

#12 = ACTION (‘maintain’, ’add this new data to an existing data set while maintaining the integrity of the original data’, #13);

#13 = ACTION_METHOD (‘PMR’, ‘update and maintain using a CIS-compatible database management system’, ’update values for Nodes’, ‘analysis revisions’);

#101 = MANAGED_DATA_SET (#1, #2, #5, #6, ‘creation date’, #10, #12, (#202, #203));

#202 = MANAGED_DATA_ITEM (‘Intergraph Frameworks 3.0-Fred Smith-001’, #303, ‘1’);

#203 = MANAGED_DATA_ITEM (‘Intergraph Frameworks 3.0-Fred Smith-002’, #304, ‘1’);

#303 = NODE (‘n’, 1, #401, #501, #601);

#304 = NODE (‘n’, 1, #402, #501, #601);

#401 = POINT (…);

#402 = POINT (…);

#501 = BOUNDARY_CONDITION (…);

#601 = ANALYSIS_MODEL (…);

It should be noted that the instances of ‘point’, ‘boundary_condition’ and ‘analysis_model’ should all be assigned meta-data. This meta-data may, but need not, be the same meta-data defined in instances #1 to #13. For simplicity, this is not shown.

It should also be noted that the UNIQUE rule UR230 forces the instance of the data entity to be unique to one instance of managed_data_item.

In the example above, the two instances of ‘node’ (#303 and #304) have been assigned the meta-data defined in instances #1 to #13. When these instances are modified by another application, the meta-data needs to be revised accordingly. However, the unique identifiers must remain the same.

The significance of the data values

For Basic CIS Translators, the values of the attributes of the entity instances contained within an exchange structure are dependent upon the application; that is, the application is free to populate the attributes as the software vendor wishes. This is not the case for DMC (and IDI) Translators. The mechanisms for data management within LPM/5 employ data entities (such as 'group' and 'action') as meta-data for other data entities. When used in this manner, the attributes of these entities are of significance for each managed_data_set and must be constrained to take the following:

	The value assigned to the attribute 'group_name' of the entity 'group' shall be set to either 'new data group', 'modified data group', or 'deleted data group'.
	The value assigned to the attribute 'name' of the entity 'person_organization_role' shall be set to either 'creating person', 'modifying person', or 'deleting person'.
	The value assigned to the attribute 'name' of the entity 'approval_status' shall be set to either 'approved', 'not approved', 'approval pending', or 'disapproved'.
	The value assigned to the attribute 'action_name' of the entity 'action' shall be set to either 'add', 'update' or 'delete'. (An 'action' is an instruction to do something with the data.)
	The value assigned to the attribute 'assigned_role_for_date_time' of the entity 'managed_data_set' shall be set to either 'creation date', 'modification date', 'deletion date', or 'approval date'.

(See diagrams in questions 1 & 5 as well as slide 30, slide 33 & slide 34)

27. "As is true with any ‘product’, there will be insufficiencies, complications, etc. that will surface at the onset of CIS/2 implementation. It is important for all of you to realize that you are not necessarily ‘stuck’ with CIS/2 as it is today! It is true we can not and will not immediately change everything, but this is not to say that we will not change a very few select items (e.g. the issue of units) in the immediate future."

"Is this statement true? Why or why not?"

We accept that there will be insufficiencies, complications, etc. that will surface at the onset of CIS/2 implementation. The scope of CIS/2 strikes a balance between the desire to include all the information that can be associated with any type of steel structure during its full life cycle, and the practical need to limit the size and complexity of the resulting model. The Logical Product Model contained in CIS/2 (LPM/5) provides for the planning, design, and construction phases of the life cycle of steel framed structures, as well the future re-engineering of structures. It also provides input into the facilities management. LPM/5 addresses low, medium and high rise construction in residential, commercial and industrial contexts. It covers both the main structural steelwork and the secondary steelwork (such as purlins, siderails, cleats and cladding).

28. "Douglas Cochrane’s comments regarding CIS/2 – Please confirm what CIS/2 can and can not accommodate in the list below:"

For individual items see the "Logical Product Model" publication.

a. "Downstream and upstream information (communicating with CAD)".

This is rather vague - CIS/2 may be able to cope with some or all of this information.

b. "Project information (not critical – name, address, etc.) – CIS/2 can accommodating".

Yes. See entities 'project', 'project_organization', 'project_plan', 'site', etc.

c. "Scheduling of the job. Sequencing and phases and individual project team member project progress".

Yes. See entities 'structural_frame_process_schedule', 'structural_frame_process_schedule_item', etc. 'project_plan', zone_of_project, etc.

d. Bill of materials is needed.

While LPM/5 does not have entities named ‘drawing’, or ‘Bill of Materials’, it does have constructs that allow applications to represent the equivalent information. That is, in LPM/5 a ‘drawing’ is merely a ‘conveyor’ of information; it is the information content of the drawing that is of interest to the CIS, rather than the drawing itself. Thus, a group could represent a drawing and the information content of the drawing is assigned through the group_assignment entity and its subtypes. In such a case, the group.group_name would represent the ‘drawing number’. Of course, CAD drawings often contain ‘layers’ that are used to separate the different types of information captured by the drawing. In such a case, a group represents a single layer of a drawing and the group.group_name would represent the ‘layer number’. The group_relationship is then used to assign the layer to its parent drawing. For example, if ‘Layer 1’ of a drawing contains the building grid, then the grid_of_building instance is assigned to the group representing ‘Layer 1’ using the group_of_structural_data subtype of group_assignment.

A similar argument holds for ‘schedules’, ‘Bills of Materials’, or any other ‘container of information. For example, a group could be used to represent an electronic CAD file with the group.group_name set to the name of the electronic file.

e. Drawings – viewpoint of a world that does not include CAD drawings. However, we still have drawings. We must keep track of drawings. Status and revision of drawings, for example.

See 'd' above. Meta-data may be assigned to a group in the same way that it is for other engineering data. That is, the status and revision of drawings would be captured through the 'data_management_set' entity and its related constructs.

f. Operations – i.e. what must be done to the steel – e.g. welds, copes, drilling, etc.

'Operations' are represented using the LPM/5 entity 'structural_frame_process' and its subtypes 'cut', 'bend', 'move', 'assemble', etc.

g. Drawings – NC files passed to the fabricator (just path and file name) as well as path and file name to the CAD drawings themselves.

See 'd' above. The CIS was never intended to capture NC data.

h. The upstream items needed are tracking of changes and status of all facets involved with a project.

This would be captured through the 'data_management_set' entity and its related constructs.

29. How do we transition from CIS/1 to CIS/2? How do we handle backward compatibility between CIS/1 and CIS/2 and just data in general?

Unfortunately, CIS/2 is not directly upwardly compatible with CIS/1. This is because the demands on CIS/2 for greater functionality and finer granularity required a complete overhaul of the LPM. It is our intention that CIS/2 will be upwardly compatible with any future release of the CIS. All the engineering information contained in CIS/1 is contained in CIS/2. Thus, it is possible to convert a CIS/1-compatible file into a CIS/2-compatible file. It is also possible for a CIS/2-compatible file containing information within the scope of CIS/1 to be converted into a CIS/1-compatible file. Several CIS/2 entities appear in CIS/1. Some have had attributes added, while others have been split into several entities for finer granularity. A future publication will describe the mapping process.

The starting point for LPM/5 was LPM4CIS (the version of the LPM included in CIS/1). This was developed to support physical file exchange. To make LPM4CIS more suitable for implementation in a DMBS, the EXPRESS schema was rationalized to remove the "compromises". This meant that:

	Some of the SUBTYPE entities that had been removed from LPM/4 were put back in.
	Some of the associative entities removed from LPM/4 were put back in.
	The "discriminator attributes" were removed.
	The relational (parent-child) nature of the model was rationalized.
	Common attributes (name, description) were inherited from SUPERTYPEs.
	Entity names were allowed to be as long as was required – abbreviations were avoided.

To assist the creation and maintenance of the EXPRESS schema, all the entities were renamed to reflect their inheritance. For example, the LPM4CIS entities 'DESIGN_ASSEMBLY' and 'MANUFACT_ASBLY' were renamed for LPM/5 as 'assembly_design' and 'assembly_manufacturing'. This may seem a trivial point, but it becomes increasingly important as the model enlarges, from 120 entities to over 560 entities.

30. WE NEED DETAILED CASE-STUDIES. THIS WILL BE THE PROOF EVERY ONE NEEDS. Do you have any thorough case studies we can use from projects completed in the U.K. and Europe using CIS or any form of EDI?

These will be the subject of future publications.

31. We need a DEP equivalent for CIS/2. We need Andrew to provide us with one?

For the reasons discussed in Q32, it would be pointless for me to generate such a thing. What I believe you are seeking is a specification for the information that will be exchanged between a group of applications. For example, the information exchanged between QSE Space and StruCAD. This information is represented using several entities in LPM/5. This grouping of entities is a Conformance Class. However, the information exchanged between QSE Space and StruCAD may change in different scope and context everytime the translators on these two applications are used. Thus, the equivalence you seek needs to be defined for each and every occurrence of information exchange between the two applications. By definition, a CIS/2 data exchange file (conforming to STEP Part 21) will conform to at least one complete Base-CC.

For initial implementations of CIS/2, I am prepared to specify the possible Base-CCs that may be used with given situations of information exchanged between given applications if I am provided with detailed and illustrated descriptions of the information.

32. "What did you learn from DEP?"

LPM4CIS contained only 120 entities. It was further subdivided into simplified implementable subsets known as Data Exchange Protocols (DEPs). While the CIS specifies how information must be structured within each CIS exchange file, the DEPs specify precisely what information must be transferred between applications, and when the particular DEP should be used. CIS/1, defined four DEPs:

	DEP1: Analysis,
	DEP2: Member Design,
	DEP3: Connection Design, and
	DEP4: Detailing.

Each of these DEPs supports the exchange of data between applications concerned with the appropriate activity. For example, DEP1 covers data resulting from the activity of structural analysis. Similarly, DEP4 covers the data resulting from the activity of structural steelwork detailing. Each DEP allows data exchange to take place based on a particular data exchange schema. However, each schema is a constrained and annotated edition of the EXPRESS representation of the common generic CIMsteel Product Model (LPM4CIS). Each of the four DEPs effectively shares the same basic data model - with the same number of entities and attributes. Removing the OPTIONAL statement preceding the attribute's data type effects constraints. Whereas LPM4CIS could be seen as a flexible means of representing information concerned with structural steel building frames, the DEPs were seen as a means of facilitating specific data exchange. That is, while LPM4CIS was generic, the DEPs were specific but could be used in combination.

This was a concept that the implementers of the CIS/1 found very difficult to grasp, since the documentation for CIS/1 included five EXPRESS schemas: one for each DEP, plus the generic LPM schema. It also had the major disadvantage of adding considerable bulk to the documentation. This was done so that each DEP could be a "stand alone" standard, which could (in theory) be distributed separately from the other CIS documents. Further DEPs could then be added as required. However, maintaining consistency between five EXPRESS schemas proved to be extremely difficult.

By late 1997, there were around a dozen applications claiming some sort of CIS-compatibility. Unfortunately, no application was able to meet all of the requirements for CIS-compatibility specified in the CIS. This was partly because the DEP mechanism was both too flexible and too broad. The scope of each of the DEPs was greater than the scope of information that any of the vendors’ applications could support. Yet, at the same time, the DEP mechanism was flexible enough to allow vendors to produce DEP-compatible files that were of completely different scopes.

Vendors requested a more "fine-grained" mechanism for data exchange, and suggested the use of "sub-DEPs"; i.e. dividing each of the DEPs into even smaller implementation subsets. The overhead in documentation and maintenance that this would have required effectively ruled out this proposal. CIS/2 sought a better solution; a solution that required only one EXPRESS schema. Thus, the mechanism for implementation and testing of LPM/5 is that of STEP; i.e. Conformance Classes.

What is a Conformance Class?

A Conformance Class is a valid subset of the LPM/5 EXPRESS schema. A CC is specified as a list of entities, together with appropriate rules for implementation. If instances of these entities were created and their attributes correctly populated, the set of data produced would be coherent and valid. This data set would be complete in itself, and if it is exported from the STEP data repository, a valid STEP Part 21 file should result. A CC is defined such that if all the entities contained in the CC were placed in a schema, the schema would be valid and independent of LPM/5. More importantly, the information conforming to a CC is interoperable with the complete LPM/5 schema.

It should be noted that CIS/2 does not define a schema for each CC, merely a list of entities with associated rules.

What is a Base-CC?

If a Conformance Class specifies a subset of LPM/5 that is complete with all the references resolved, a valid schema may be defined, and the CC is said to be ‘complete’. If a valid schema cannot be defined from the CC, it said to be ‘incomplete’. CIS/2 does not define Conformance Classes explicitly; it merely specifies a large number of ‘Base CCs’, some of which are complete, while some are incomplete.

The role of the Base CCs is to define minimal subsets for each non-ABSTRACT entity in LPM/5. In the case of a complete Base CC, a valid subset of LPM/5 is defined for that entity. An incomplete Base CC, on the other hand, must be combined with other Base CCs before it can be implemented.

Why does CIS/2 use Base-CCs?

CIS/1 used the concept of Data Exchange Protocols (DEPs) and defined four DEPs to cover broad areas of analysis, member design, connection design and detailing. Unfortunately, these DEPs proved to be too broad in scope and too flexible on implementation to enforce rigorous testing. CIS/2 uses the approach to implementation and testing used by STEP; i.e. Conformance Classes (CCs). This is one of the most significant differences between CIS/1 and CIS/2; one which had a major influence on the size and style of the model for implementation. Since CCs operate at an entity level (rather than the attribute level of a DEP), a CIS-compatible application must support all the attributes of all the entities within the specified CC.

The LPM/5 long form EXPRESS schema is an extremely large and complex ‘Product Model’ containing 568 entities, 116 types, 64 functions, and 1 global rule. Further complexity (and functionality) is added to LPM/5 on implementation due to the large number of ANDOR SUPERTYPEs. When these are resolved, an ‘object model’ containing over 2000 ‘entity objects’ may be produced. Moreover, LPM/5 is not a simple hierarchy of ‘classified types’ but a network of interrelated ‘entity objects’ that may be populated in many different ways to reflect their information content.

Although it is theoretically possible to define CCs for each and every permutation of the possible populations of the LPM, it would not be practical to do so, as it would result in the creation of several hundred thousand CCs. The creation of ‘modular’ or ‘Base’ Conformance Classes was seen to be the more realistic approach. These Base CCs are then put together as required for implementation and testing.

Put simply, LPM/5 is far larger in scope and has a much greater range of functionality than any existing engineering software application. Thus, it is highly unlikely that any application vendor would implement the LPM/5 EXPRESS schema in its entirety. Furthermore, data is exchanged in small packets. Given the life cycle of a steel structure, large exchanges of ‘complete’ models will be rare. Therefore, LPM/5 was broken down into smaller manageable pieces. These pieces, known as Base CCs, may be combined in many different ways to define a specific collection of information.

Obviously, the scope of the application will be greater than that of an individual Base CC, but the information that its end users will wish to share will fit into one or more combinations of Base CCs. The vendor of the engineering software application seeking CIS/2-compatibility is at liberty to choose how the Base CCs are combined (subject to the rules defined for each BASE CC).

This is discussed in the "Conformance Requirements" publication.

CIS/2

Questions raised during the

AISC CIS Technical Workshop Part I

17-19th Feb 1999, California

Note: This page refers to the beta version of LPM/5. Some of the answers below are no longer appropriate to the formal issue version of LPM/5. For the latest information see the CIS - FAQ section on this web site.

1. "Is the ID information associated with meta-data application-specific?"

2. "How is the meta-data ID generated?"

3. "What is the point of creating an abstract supertype with only one child?"

4. "Can you store who did the fabrication work on a member?"

5. "Can you add more meta-data?"