Overview

This document describes the generalized approach of populating metadata of an asset. There can be several scenarios and contexts in which metadata of an asset is populated. There needs to be a generalized approach on how to address this in various contexts.

Types of Metadata

The metadata can be broadly looked at based on the following two categories:

1. Framework metadata

2. Object specific metadata

Framework metadata

A framework defines a related set of attributes - typically based on a domain - that are common across different (or all) types of assets. A framework is primarily to organize a set of assets related to a domain for easy discoverability. It is very similar to how books are organized in a library or a book shop.

Although tagging assets to framework attributes is primarily for organization, it can also be used for the following purposes:

• Discovery of relevant assets by searching and filtering, using the attributes

• Targeting assets to certain audience - a framework that defines attributes of audience can be used for this purpose

• Analyze data based on framework attributes to get insights

Each framework attribute usually consists of a list of possible values to tag. The list of values could be a flat list or a hierarchy. There can be relation between the attributes in a framework.

Framework specific metadata is the set of attributes of an asset that come from a framework. The framework type and framework value are also part of the framework specific metadata.

Details of tagging assets using frameworks is detailed in this page: https://project-sunbird.atlassian.net/wiki/spaces/SingleSource/pages/2477260803

Object specific metadata

Object specific metadata are the set of attributes inherent to an object type. There may be certain attributes common across all object types - such as Name, Description etc. There may be certain attributes that are specific to certain object types, for example, “Maximum number of attempts” could be an attribute specific to a question type object.

Object specific metadata is typically used for:

• Give context and understanding about the object. Example: Name, Description etc.

• Defining certain behavior of an object. Example: “Maximum number of attempts”, “Visibility”, etc.

• Discoverability. Example: Keywords

These two types of metadata have to be looked at differently, at least from perspective of populating the values. The reason is, these two types of metadata have differences in which they are populated, in different contexts. Following sections detail the functionality of populating these two types of metadata.

Framework metadata population

Assets can be tagged with framework metadata in two different contexts:

1. When asset is created as part of a sourcing project

2. When asset is created independent of a sourcing project

When assets are created as part of a sourcing project, the context of the framework to which the assets are being sourced is present as part of the scope of the sourcing project. Hence the metadata population has to happen in that context.

When assets are created independent of a sourcing project, the context of the framework will have to come from the primary category of the asset being created.

Following sections detail how the metadata population happen in these two contexts.

Asset created under a sourcing project

Configuration

1. Set of framework types to be used for any sourcing project

   1. This will be a list of framework types that can be used to source assets using sourcing project.

   2. It is an ordered list.

   3. This is can be configured at system level. It can be overridden at each tenant level.

   4. This is used to show the list of frameworks during project creation.

2. Framework form configuration for each framework type

   1. This is can be configured at system level. It can be overridden at each tenant level.

   2. This form is used to populate framework fields, both during project creation as well as for the Edit/Review metadata form of an asset.

   3. The form will have the following details:

      1. Framework related fields to be used

      2. The UI behavior of each field - labels, placeholders, dropdown/tree selector, required/not required, multi-select/single-select, visible/non-visible, order, dependencies between the fields

      3. Default value to be taken for non-visible fields.

      4. Mapping to object framework metadata ids - example board ids, subject ids

      5. The order in which the fields have to be shown

      6. Grouping of the fields into sections (along with section labels) if required

   4. The form can have both Org framework and Target framework metadata. But for the current scope only Org framework will be configured.

Workflows

Create Project of the type “Seek assets for Target Collections”

1. User creates a project and fills in the required details

2. User goes to “Project Scope” section

3. User selects target collection type and content types

4. User sees a dropdown of frameworks as per the “Set of framework types to be used for any sourcing project” configuration

   1. For each framework type in the configuration, system checks if there is a framework of that type in the tenant. If present, it will take that. Else it will look for the same framework type at system level and take that. If the framework type is neither present in tenant or at system level, an error message “Incorrect framework configuration. Please contact system support.” is shown.

   2. Based on the above logic, list of frameworks are shown. The frameworks are in the same order in which framework types are configured.

   3. The first framework in the list is chosen by default. User can change it if required.

5. Based on the framework chosen in step 4, the system shows set of filters using the “Form configuration for selected framework type”.

   1. The fields are populated with values as in the selected framework.

   2. The fields are shown as dropdown or topic selector as per the config.

   3. The fields which are configured as “visible” are shown in the same order as per the config.

   4. For the fields configured that are “not visible”, the values are selected as per the default values.

   5. User can select the values of fields that are “visible”.

   6. Dependencies between the fields are maintained as per the form and framework configuration

   7. “Required/Not required”, “Multi select/single select” are not applicable in this flow for filtering. No field is required. Any field is multi select.

   8. User can select one or more values from one or more fields and click “Apply”

   9. Filters are applied as per the selected framework values on the selected target collection type and the results are displayed in the table.

   10. The table has following columns in that order

       1. Title - name of the collection

       2. One column each for the first three framework fields configured in the framework form for the selected framework type

       3. First level folder name of the collection - as per the primary category configuration of the selected collection type

The rest of the project flow remains as is.

Create Project of type “Seek assets NOT for any Target Collections”

1. User creates a project and fills in the required details

2. User goes to “Project Scope” section

3. User selects content types

4. User sees a dropdown of frameworks as per the “Set of framework types to be used for any sourcing project” configuration

   1. For each framework type in the configuration, system checks if there is a framework of that type in the tenant. If present, it will take that. Else it will look for the same framework type at system level and take that. If the framework type is neither present in tenant or at system level, an error message “Incorrect framework configuration. Please contact system support.” is shown.

   2. Based on the above logic, list of frameworks are shown. The frameworks are in the same order in which framework types are configured.

   3. The first framework in the list is chosen by default. User can change it if required.

5. Based on the framework chosen in step 4, the system shows set of filters using the “Form configuration for selected framework type”.

   1. The fields are populated with values as in the selected framework.

   2. The fields are shown as dropdown or topic selector as per the config.

   3. The fields which are configured as “visible” are shown in the same order as per the config.

   4. For the fields configured that are “not visible”, the values are selected as per the default values.

   5. User can select the values of fields that are “visible”.

   6. Dependencies between the fields are maintained as per the form and framework configuration

   7. “Required/Not required”, “Multi select/single select” are not applicable in this flow for filtering. No field is required. Any field is multi select.

   8. User can select one or more values from one or more fields.

6. User saves or publishes the project.

7. The framework chosen at step 4 and the framework values selected in step 5 are stored as part of the project scope.

Project Page

In case the project is of type “Seek assets not for any target collection”, the framework name and the list of framework values selected as part of the project scope - as an information text.

The table that shows collections or content will have the following columns:

1. Title - of the collection or content

2. One column each for the first three framework fields configured in the framework form for the selected framework type

3. First level folder name of the collection - as per the primary category configuration of the selected collection type

4. Status

Create/Modify Asset - Edit Metadata of an Asset

1. User creates/modifies an asset

2. User opens metadata form to modify the metadata (can be content or question set)

3. The metadata form contains

   1. Fields related to object metadata - Populated based on primary category configuration of the asset

   2. Fields related to framework metadata - Populated based on the “Form configuration for selected framework type” - depending on the framework selected as part of the project scope.

4. Fields related to framework metadata

   1. Fields related to framework metadata will be a separate section and have the following functionality. Note: this is same for all assets and whether the asset is created for a target collection or not within the sourcing project.

      1. The fields are shown as dropdown or topic selector as per the config.

      2. The fields which are configured as “visible” are shown in the same order as per the config.

      3. For the fields configured that are “not visible”, the values are selected as per the default values.

      4. User can select the values of fields that are “visible”.

      5. If the field is “Multi select”, user can select multiple values. There will also be a “Select all” option. If the field is “Single select” only one value can be selected.

      6. If a field is “Required”, it will have a red asterisk. User is not allowed to submit the asset for review without filling required fields. The required fields that are not filled are highlighted in red when user tries to submit the asset for review.

      7. Dependencies between the fields are maintained as per the form and framework configuration

   2. Population of values in the framework metadata fields

      1. In case the asset is created for a target collection

         1. Framework value is the same as that of target collection

         2. In each framework metadata field, the values of the corresponding field in target collection are populated. User can select values only from that subset to populate in the asset.

         3. In case the target collection doesn’t have any value for a given field, all possible values from the framework are populated.

         4. In case there are dependent values, only the subset of dependent values are populated.

      2. In case the asset is created NOT for a target collection

         1. Framework value is the same as that of sourcing project

         2. In each framework metadata field, the framework values of the corresponding field in the project scope are populated. User can select values only from that subset to populate in the asset.

         3. In case the project scope doesn’t have any value for a given field, all possible values from the framework are populated.

         4. In case there are dependent values, only the subset of dependent values are populated.

Review Asset - View Metadata of an Asset

The flow is as existing.

1. The framework metadata fields are shown as separate section, as per the form configuration.

2. All the populated values by creator are shown in a read only mode

Asset created independently (not in a sourcing project)

Configuration

1. Set of framework types to be used to tag the given primary category of asset when created independently (not in sourcing project)

   1. This is part of primary category configuration. It can be configured at system level for each primary category. It can be overridden at tenant level for each primary category.

   2. This will be a list of framework types that can be used to tag an asset of this primary category, when created outside a sourcing project

   3. It is an ordered list.

   4. This is used to show the list of frameworks during asset creation/editing.

2. Framework form configuration for each framework type

   1. This is part of primary category configuration. It can be configured at system level for each primary category. It can be overridden at tenant level for each primary category.

   2. This form is used to populate framework fields for the Edit/Review metadata form of an asset being created outside a sourcing project.

   3. The form will have the following details:

      1. Framework related fields to be used

      2. The UI behavior of each field - labels, placeholders, dropdown/tree selector, required/not required, multi-select/single-select, visible/non-visible, order, dependencies between the fields

      3. Default value to be taken for non-visible fields.

      4. Mapping to object framework metadata ids - example board ids, subject ids

      5. The order in which the fields have to be shown

      6. Grouping of the fields into sections (along with section labels) if required

   4. The form can have both Org framework and Target framework metadata. But for the current scope only Org framework will be configured.

Workflows

This section details the workflows related to asset creation/modification outside the scope of a sourcing project. This mainly happens when an asset is created or modified in “Workspace”.

A “workspace” is primarily used by a sourcing organization to manage their assets. Sourcing organizations can create, modify and publish assets without creating a specific sourcing project to source assets. This already exists as part of consumption portal currently and will be moved to sourcing portal.

The same concept of “workspace”, in future can also be extended to contributors (organizations and individuals). Whitelisted contributors can have a workspace of their own to manage their assets. This will help create a warehouse of assets which can be used by sourcing organizations to dip into and publish the assets as per their needs.

Create/Modify Asset - Edit Metadata of an Asset

1. User creates/modifies an asset in workspace.

2. User opens metadata form to modify the metadata (can be of any object type)

3. The metadata form contains

   1. Fields related to object metadata - Populated based on primary category configuration of the asset

   2. Field to select framework - Populated based on the “Set of framework types” configured as part of the primary category configuration.

   3. Fields related to the selected framework - Populated based on the “Framework form configuration” of the configured as part of the primary category configuration - depending on the framework selected above.

4. Selecting a framework

   1. Framework will be a drop down with list of framework names.

   2. This list is populated based on the set of framework types configured as part of the primary category configuration. The list will be in the same order as configured. The first framework will be selected by default.

   3. For each framework type configured in the primary category configuration,

      1. System checks if a framework of that type exists in the tenant.

      2. If exists, it populates that framework name.

      3. If a framework of given type doesn’t exist at tenant level, system checks for the same at system level.

      4. If exists, it populates that framework name.

   4. Following are error conditions. In case of these errors a message stating - “Incorrect framework configuration. Please contact system administrator” is shown to the user when editor is launched.

      1. No framework of a framework type exists at tenant or system level

      2. There is more than one framework of the same type found (either at tenant level or at system level)

   5. There can be a scenario where no framework types are configured. In this case the field is not shown. Subsequent set of fields related to framework metadata is also not shown.

5. Display fields related to framework metadata

   1. Fields related to framework metadata will be a separate section.

   2. The fields are populated based on the framework selected in the previous step. Based on the selected framework, system uses corresponding “Framework form configuration” of the configured as part of the primary category configuration to populate the fields.

      1. The fields are shown as dropdown or topic selector as per the config.

      2. The fields which are configured as “visible” are shown in the same order as per the config.

      3. For the fields configured that are “not visible”, the values are selected as per the default values.

      4. User can select the values of fields that are “visible”.

      5. If the field is “Multi select”, user can select multiple values. There will also be a “Select all” option. If the field is “Single select” only one value can be selected.

      6. If a field is “Required”, it will have a red asterisk. User is not allowed to submit the asset for review without filling required fields. The required fields that are not filled are highlighted in red when user tries to submit the asset for review.

      7. Dependencies between the fields are maintained as per the form and framework configuration

6. Population of values in the framework metadata fields

   1. In case the asset is created under a target collection

      1. Framework value is the same as that of target collection. In case primary category definition of the asset doesn’t have the framework type as set in target collection, default value (first in the list as defined in primary category definition) is set.

      2. In each framework metadata field, the values of the corresponding field in target collection are populated. User can select values only from that subset to populate in the asset.

      3. In case the target collection doesn’t have any value for a given field, all possible values from the framework are populated.

      4. In case there are dependent values, only the subset of dependent values are populated.

   2. In case the asset is created NOT created under a target collection

      1. Framework value is set to default (first in the list as defined in primary category definition).

      2. In each framework metadata field, the framework values of the corresponding field are populated based on the framework.

      3. In case there are dependent values, only the subset of dependent values are populated.

Review Asset - View Metadata of an Asset

The flow is as existing.

1. The framework metadata fields are shown as separate section, as per the form configuration.

2. All the populated values by creator are shown in a read only mode

Add Asset to a collection - Search assets

This is the flow where an existing asset is added to a collection using “Add from Library” option in the collection editor. This happens through “Workspace”. As part of this flow, users will be shown a search form to search and filter relevant assets. The search filters are based on framework attributes. Here is how these filters should be populated:

1. The framework attributes that are shown in search form as filters should be based on what is configured in the primary category of the collection

   1. In case collection has both org and target frameworks configured, both have to be shown in the search form

   2. If only one framework (org) is configured, it has to be shown in the search form

2. The default values selected should be the corresponding values of the collection.

3. When user selects certain values from the filters and applies, the assets have to be filtered based on the selected framework attributes.

Object metadata population

As the object metadata are attributes inherent to an object type, the population of the metadata is same whether in the context of a sourcing project or outside. The set of attributes are driven by the configuration of the primary category of the asset.

However, when an asset is created as part of a target collection, certain attributes may have to be prepopulated from the target collection. The configuration and workflows for the same are detailed in the following sections.

Configuration

1. Object Metadata form configuration for each primary category

   1. This is part of primary category configuration. It can be configured at system level for each primary category. It can be overridden at tenant level for each primary category.

   2. This form is used to populate object metadata fields, for Edit/Review metadata of an asset.

   3. The form will have the following details:

      1. Object metadata related fields to be used

      2. The UI behavior of each field - labels, placeholders, dropdown/tree selector, required/not required, multi-select/single-select, visible/non-visible, order etc.

      3. Default value to be taken

      4. Grouping of the fields into sections (along with section labels) if required

2. Object metadata to prepopulate from target collection

   1. This is part of primary category configuration. It can be configured at system level for each primary category. It can be overridden at tenant level for each primary category.

   2. This is used when an asset is being created for a target collection. It will be used to prepopulate values of certain object metadata attributes from target collection as configured.

   3. The configuration will have a list of object metadata attributes that need to be prepopulated to the asset from target collection.

Workflows

Note: This functionality is same when an asset is created as part of a sourcing project or outside a sourcing project.

Create/Modify Asset - Edit Metadata of an Asset

1. User creates/modifies an asset

2. User opens metadata form to modify the metadata (can be content or question set)

3. The metadata form contains

   1. Fields related to object metadata - Populated based on primary category configuration of the asset

   2. Fields related to framework metadata - Populated based on the “Form configuration for selected framework type” - depending on the framework selected as part of the project scope.

4. Fields related to object metadata

5. Fields related to object metadata will be a separate section and have the following functionality.

   1. The fields are populated based on the Object metadata form configuration that is part of the primary category asset definition of the asset being created/edited

   2. The fields follow all the existing behavior such as visible/not visible, required/not required, type of input (like textbox, text area, dropdown etc.), multi-select/single select (in case of dropdown), placeholder, default value etc. will be configurable as part of form configuration and form fields are populated accordingly.

6. Population of values in the object metadata fields

   1. In case the asset is created for a target collection, there may be certain fields that have to be prepopulated from corresponding target collection metadata attributes. This will be based on the “Object metadata to prepopulate from target collection” that is part of the primary category asset definition of the asset being created/edited.

   2. In case the asset is NOT created for a target collection, no pre-population (apart from any default value configured in step 4 above) is populated.