アクティビティは生じたり起きたりした事柄である。それは、言語でいう動詞に当たる。STEPlibでは、能動的なフォーム、受動的なフォーム及び名詞なフォームは、同意語と見なされる。例えば、行動act、行動するacting及び行為actionはアクティビティクラスの3ケの名前である。

　STEPlibは、どれらが、人間によって実行されるものか、あるいは、物理的もしくは化学的なプロセスであろうが、その疑問の差に関係なく、アクティビティクラスを持つ。これらのアクティビティのクラスの幾つかは、形式化されたもので、‘Process Plant Engineering Activity Model’（AP221 annex E）に収められている。

　アクティビティクラスはプロセスプラントの全ライフサイクルをカバーして、それは計画から取り壊しに渡り、この期間でそのプラントで起こり得る組織のアクティビティや物理現象のアクティビティを含んでいる。

　STEPlibでのアクティビティクラスは、アクティビティもパフォーマもイネイブラも含まない。例えば、‘design’, ‘maintain’や‘repair’は、アクティビティクラスであるが、ポンプの設計やポンプの修繕はサブクラスには存在しない。もし、それをするのに、いろんな可能性を組合せると、クラスの組合せが爆発してしまう。

　特定のアクティビティは、次の様に記述できる：

　

　AP221では、時間の経過に従って発生するものをアクティビティと呼んでいる。従って、蒸留とか工事とかいったプロセスはアクティビティのサブクラスとして定義される。また、制御や計測や動作といったプロセス制御のプロセスは、アクティビティのサブクラスになる。従ってこれらのプロセスは、クラスライブラリでは、アクティビティクラスと同様の扱いになる。

　アクティビティクラスに含まれる物理プロセスの例としては、蒸留や反応や触媒による破損や熱伝導や運送などがある。

　また受動的‘passive’なアクティビティやイベントも、アクティビティクラスに含まれる。例えば、汚染や不慮の出来事やトリップやクラックなどがある。

　機能functionという用語は、実際にはいろんな形で使われる。ある場合には、機能はアルゴリズムや数式であってパラメタや入出力と関連を持っている。例えば、VDI／VDE 3696 ‘control functions’といったものである。別のケースとして、機能はロールでもある、それはある人物のロール（機能）になる。最後に、機能はまた、（機能に対する）アクティビティやプロセスを示唆するものとして使われる。例えば、機能分解は、通常、達成されるべきアクティビティの分解を意味する。従って、機能のSTEPlibクラスはアクティビティやロールや関係（数学関数）のサブタイプとして記録されるべきものである。

　

　情報は一般的にオブジェクトが必要とするものの集まりである。そういった情報は、通常はアクティビティを必要とし、あるいはアクティビティから生まれる。それは、ファイルや文書に記録されるもので、データシートや部品表や物質バランス表などである。それらオブジェクトによって保持されているものの集まりは、コンテキストと呼ばれる特定の見方によって集められた、該当する事実facts の集まりを含んでいる。それはいつも、オブジェクトにまつわる全ての事実のサブセットである。オブジェクトに関する事実の完璧な集まりの組合せは、製品モデルproduct modelと呼ばれる。その様な、事実に関する要件や結果はクエリーqueryの形で定義される。

　それは新しい製品モデルをindividualかindividualクラスに対してつくるために、’fill in the blanks’形式のテンプレートを定義することも可能である。そのテンプレートは、空欄の意味が文字で定義されている‘empty form’に例えられる。

　例えば、AP221の言葉では、渦巻きポンプのデータ／管理シートは、ポンプユニットのatomic factsを定義する。各々のatomic factは、オブジェクトの組合せから成っている、ポンプ構成要素とか性状とか、数値とかといったもので、プロパティクラスの組合せの分類とポンプ要素やアクティビティのクラスなどである。

　一方では、そのテンプレートは暗黙にポンプを手配し、その為のデータシートを印刷するデータを選択するqueryを定義する。

　アプリケーションは、正しく運用する為には、これらのテンプレートの定義を必要とする。STEPlibはテンプレートに、物理オブジェクトクラスの共通な特性の定義を含んでいる。例えば、STEPlibは次のようなfactsを持っている：

　この組合せは、その物理オブジェクトのサブタイプによって継承されている。だから、圧力容器とタンクは内部容積を持っている。

　テンプレートを定義するには、その事実を使うことが出来るが、テンプレート自体は現行では未だSTEPlibには含まれてない、ただ特定の‘交換シナリオ’に対するデータ要件は含むことができる。

　交換シナリオはデータ交換の対象とすべきデータセットを定義する。そのデータセットとはアクティビティを標準化したクラスである。

　

　例えばポンプの発注‘order a pump’は、標準的な方法で行うことが出来る。ただしこの標準的な方法がアクティビティクラス定義によって決められている必要がある。かかるアクティビティは要求されているポンプを規定するに十分な特定のデータセットを必要とする。その仕様の中身は、そのアクティビティを定義している企業によって大なり小なり詳細化されていなければならない。なので、もしこれが標準化されていれば、その標準は最低セットになることが出来る。最大セットはポンプとその部品に関係のある全ての特徴を取込んだものである。

　

　クラス名は、識別（命名）の関係を経由してクラスと関係する。この為に、同一のクラスが複数の名前、同意語のようなもの、を持つのを許している。それはまた、クラス事体が例え名前がなくても、ユニークな識別子によって完全に識別されているというのが原則であることを意味している。従って、STEPlibの全てのクラスは、グローバルにユニークな識別子を持つことを求められている。このユニークな識別子は、ユニークな番号（00001などの）で表されて、全てのクラス（ISO 10303−221のクラス）に同じものからなっている。

　これらのユニークな識別子は、外のものとの間で、同音異義語（異なるクラスに同じ名前を使う）を使う可能性を与える。ただ、それは同音異義語が最初にオブジェクトとその名前に適用できるコンテキストであるところの参照コンテキストに関係していることによって識別される必要がある。

　同音異義語はSTEPlibでは、常にその言葉が使われている‘subject area’として参照されるコンテキストによって区分される。STEPlibのクラス名は、最初は、英語による都合の良い名前‘preferred names’である。STEPlibでの同意語は、‘non-preferred alternatives’である。STEPlibの名前は、可能な限りコンテキストに依存することが望ましい。

　STEPlibは、いろんな言語での名前を許していて、各種の‘naming systems’や‘coding conventions’に則っているコーディングを提供している。

　コード化された情報の標準クラスの例としては、フランス語、ドイツ語、オランダ語、漢字などがる。

　STEPlibは、先行的に英語で作られているが、利用者は現行のクラス名の翻訳をライブラリ管理者に送るのがよい。それらをSTEPlibに含めるかは熟慮される必要がある。