Arthit Suriyawongkul
Arthit Suriyawongkul
ExpandedLicensing has these three properties: - [listVersionAdded](https://spdx.github.io/spdx-spec/v3.0.1/model/ExpandedLicensing/Properties/listVersionAdded/) - [deprecatedVersion](https://spdx.github.io/spdx-spec/v3.0.1/model/ExpandedLicensing/Properties/deprecatedVersion/) - [obsoletedBy](https://spdx.github.io/spdx-spec/v3.0.1/model/ExpandedLicensing/Properties/obsoletedBy/) `listVersionAdded` could be generalised as `versionAdded` to use with class/property/individual
@goneall We need an agreed keyword in the Markdown that the spec-parser can recognize and feed it further to the shacl2code. 1) Human put deprecation info in Markdown 2) spec-parser...
Should we move this to [`spdx-3-model`](https://github.com/spdx/spdx-3-model/) repo?
@mkurzman in case you haven't aware of this yet. thank you.
If it's valid it's good. If it's not, having some information to understand why it is the case is good.
Thanks. I will rebase / check the parameters again to keep up with latest spec-parser.
Fixed and already live on https://w3c.github.io/poe/model/
We may also need a Japanese translation of "Class hierarchy" as well. See its use here: https://spdx.github.io/spdx-spec/v3.0.1/model/Core/Classes/Agent/#class-hierarchy
Interesting. It will be handy for Profile contributors to have such an ability to create a new file with some suggested structure. If we can find ways to use that...
As examples, they are not normative. This is merely follow examples in Security Profile. Define a separate section and clearly said that these are not normative is a good idea.