Skip to content

Assets

Users need to navigate, inspect, and act upon their datasets, ML experiments, and models. In the AI& Analytics Engine's parlance, these are "assets".

Asset Hierarchy

Users' assets are organized as per the following two hierarchies:

Organization => Project => Datasets

Organization => Project => App => Model => Deployment

The user account is the root node, under which there can be multiple organizations.

For each parent asset type, there can be multiple child assets of the appropriate type. For example, under each organization, there can be multiple "projects". Each project can belong to a single organization only.

A dataset within one project can be used by one or more apps. This links the two hierarchies described above, as shown in the following schematic:

Asset Hierarchies

Asset Type Definitions and Examples

Asset Type Definition Example
Organization A user can be a member of multiple organizations (companies, departments, teams etc). Thus, multiple "Organization" nodes can exist under a single user account. Each organization has access only to assets owned by it. Assets cannot be shared across organizations.
Project Under an organization, there can be multiple projects. A project is an overarching namespace that contains a set of apps to be built from some datasets. A project can use multiple datasets under the organization it belongs to. Users belonging to a particular organization do not automatically become members of all projects in the organization. They have to be explicitly invited. Users (such as contractors etc.) who are not members of the organization can be invited as "external" users into the project. There can be a single project known as "Pedestrian Access" under "City of Melbourne" organization, that deals with making pedestrian access easy through intelligence. It will utilise three datasets: CCTV video feeds at various locations, log of electronic ticket swipes on the city's rail terminus station and on select tram lines.
Dataset The dataset that was used to train the model
Application Under a project, there can be multiple apps. In essence, each app is a specialized intelligence to perform a single prediction task, trained from one or more datasets. Each app provides a space for the user to define the task, and to train and compare several models to achieve the goal. There can be an app for counting people at various locations, using CCTV video feeds only. There can be another app that forecasts the number of pedestrian footfalls from the city's rail terminus station, based on data from electronic-ticket turnstiles at various locations.
Feature Set The feature set is a logical grouping of features that are used to build models.
Model There can be multiple models trained under the same app. Each of these models is trained from a single model template on some training data. After training, each model is evaluated on the same train/test split. This allows the user to compare and choose the best model for deployment. Hence, the app provides a space for the user to experiment with many possible models that can perform the same same task.
Deployment One of the trained models under the app is typically deployed. One can also deploy the same trained model at multiple API endpoints, in PI.EXCHANGE's cloud. Future options will include deployment on preferred cloud platform (Google Cloud, Azure, AWS, Alibaba etc.), docker image download to deploy in premises, and deployment to IoT devices. Each deployment makes the trained model's predictive power accessible through simple API calls. A prediction API can run live on a CCTV feed to automatically identify persons in a particular room in the campus in real time.