TABLE OF CONTENTS

• Introduction
• ILAP Terms for different contexts
• Content control for an ILAP Term

Introduction

The very basic information for an activity is its duration, which calendar it uses, which start and finish dates it has been assigned by the scheduling engine (based on links in network relating it to other activities), etc. What is missing from this set of fundamental properties (sometimes referred to as "Core fields") is metadata information that can classify this activity in various ways.

Typically such metadata is where it occurs (the location), which discipline it belongs to (e.g. Electrical work), which WBS (Work Breakdown Structure) it belongs to, etc., etc.

In IDE we call this metadata "an ILAP Term".

ILAP Terms for different contexts

Since the list of ILAP Terms can be, philosophically speaking, "endless" (since the car industry may have a very different metadata requirements than Oil and Gas for an activity) - we need a construct by which to add such named pieces of metadata.

The first context to specify, is which "level" the meta data belongs to. Currently IDE supports 3 levels:

1. Schedule level
2. Activity level
3. Resource Assignment level

After this we have 2 other contexts in which to add ILAP Terms:

1. "Globally available ILAP Terms" - added by System Admin where each added term is available for all tenants (but each tenant can decide if they want it visible or not in their list of ILAP Terms).
2. "Tenant specific ILAP Terms" - added by Tenant Admin, if the term is not found in the Global list of ILAP Terms. System Admin may later decide to "promote" such a term to a Global level.

Content control for an ILAP Term

Even if an ILAP Term is added as "Global ILAP Term", it can still be given a classification at to what level of "ontological maturity" it has...

In reality this means specifying if the ILAP Term should be considered to be at "System" level - i.e. its values are considered as part of an ISO standard. An example of this could be "Country Codes", where the ISO 3166 has a well defined list of valid codes. Such an ILAP Terms should preferably contain in its name the ISO standard that it adheres to, e.g.: "ISO3166_Country".

The other option for classifying the "ontological maturity" of an ILAP terms is "Template or Tenant" - i.e the tenant using the term can determine if the list of valid values should be defined at Tenant level or be left to the Template to control.

Host Specific ILAP Terms - a hidden 3rd type of ILAP term

When making a Template, you will be able to choose which ILAP Terms to use from your Global and Tenant Specific list. 

But in addition to these, you may on rare occasions need to control details of how data flows from one Safran schedule to another, or from one P6 schedule to another (i.e 2 scheduling tools of the same kind). 

In these cases you can add from a list of pre-defined ILAP Terms corresponding to the API for that particular scheduling tool, and thereby control how data is mapped at a very detailed level. 

When making a Config for template containing such ILAP Terms, you will get default mappings to the corresponding API field, but can override these.