Chin Yeung

Here are couple of items to address: 1. For the renaming/key mapping process, we can use the `transform` utility to help (https://aboutcode-toolkit.readthedocs.io/en/latest/reference.html#transform) 2. The errors shown above (Both ERROR and...

I think the `transform` is the way for this issue. That's to create a sepecifc transform config file for the field renaming for the nexB-specific inventories.

actually I was thinking about this earlier as the "name" field is only meaningful for component but not for package.

reopen this as for some reasons, the `name` is required at the current code. Need to investigate again if the `name` is needed.

Need to update the SPEC as the current SPEC treat name as a mandatory field (https://github.com/nexB/aboutcode-toolkit/blob/develop/SPECIFICATION.rst#other-mandatory-fields)

actually from the attribution prespective, I think `name` is quite useful. For instance, ``` /project/org/apache/commons/logging/1.1/ ``` if the ABOUT file doesn't have the name field, the attribution will not look...

I am grouping this to https://github.com/orgs/nexB/projects/23 as this is related to attribution.

Closing this. `name` should be mandatory and this is the only mandatory field.

All these filtering, is likely, can be done via the template as long as the input has the proper fields to indicate if it's a package, source file etc...

do we really want/need to support `is_product` field? By "support" mean the value need to be validated. If multiple values can be applied, it's hard to validate. perhaps we don't...