Arthit Suriyawongkul

@stevenc-stb this could be related to Standard - and Specification we have discussed in Tech and AI Team meetings

@colin-pm I see irrelevant changes in two files below that may be added accidentally? Would you mind to remove them from the changeset please? Thank you. - serialization/json.md - serialization/jsonld/validation.md

> > * Since we have U.S. Cyber Trust Mark in the example, I guess the intention of this Regulation class includes regulations of both mandatory and voluntary nature. >...

The Hardware Profile group just kindly shared with us yesterday (2025-04-29 AI Team Meeting, see [tentative minutes here](https://spdx.swinslow.net/p/spdx-ai-minutes)) a diagram of Specfication class from their Hardware Profile proposal: ![Regulation as...

@stevenc-stb I agree that "mandatory" is unclear. Another related terminology is "binding" and "non-binding". For me, if it is a property, it should be something intrinsic to the instance (a...

Notes: We may also able to use or link with the Dublin Core terms "conformsTo" as well: https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#http://purl.org/dc/terms/conformsTo

> An Attestation class or relationship should be what certifies that an Artifact meets a Regulation. The Attestation could be supported by evidence though a relationship of some form. @colin-pm...

I think we can merge this to the profile-hardware branch now

> I'm not sure what to do about 3.0.1, as this will unfortunately affect it. If we want this to be available in 3.0.1 SHACL, we have to rerun the...

@kestewart Should we merge this to the `profile-hardware` branch?