4f536a2 does not bind artifactID to a specification name

[ElectricNroff]

In 5.1.1, a property named cpeApplicability was introduced, containing the same information as an NVD configurations property. Although this choice resolved a naming conflict, the words "cpe" and "Applicability" also made it possible for many consumers to discern the meaning of the data structure without reading the schema documentation.

As mentioned in the #426 issue, 4f536a2 introduced the artifactID property. This approach is not analogous in the sense that few persons in the vulnerability management community immediately think of OmniBOR when seeing the term "artifact ID." (It is, of course, hoped that the number of such persons will vastly grow over time.)

For example, "artifact ID" is also widely associated with Maven today: https://maven.apache.org/repositories/artifacts.html

To further document the history of 4f536a2 and provide guidance on adding other properties in the future, it would be useful to capture notes about:

1. should CVE Record Format data structure naming include the common name of the underlying specification (such as "cpe" or "OmniBOR")?
2. which CVE user personas are affected by the decision?

[alilleybrinker]

Given that the documentation for the field explicitly references OmniBOR I don't know how much of a problem this is in practice. If folks feel strongly about calling the fields omniborArtifactID and omniborArtifactType instead of artifactID and artifactType that's fine with me, but I don't think it's necessary.

[alilleybrinker]

Discussed in today's QWG meeting, will rename fields to omniborArtifactID and omniborArtifactType.

[alilleybrinker]

@ElectricNroff or @ccoffin this can be closed, as PR #410 has been updated to use the new field names.