Add creationInfo to named individuals

[bact]

Add creationInfo to named individuals, so it will pass the validation.

To fix #153

Based on #153 (comment) and rely on SpdxOrganization individual to be created from spdx/spdx-3-model#880

--

Generated spdx-model.ttl:

@prefix ns1: <https://spdx.org/rdf/3.0.1/terms/Core/> .
@prefix ns7: <https://spdx.org/rdf/3.0.1/terms/ExpandedLicensing/> 

ns1:_SpdxOrganization a owl:NamedIndividual,
        ns1:Organization ;
    rdfs:comment "SPDX Project"@en ;
    ns1:creationInfo _:_CreationInfo ;
    ns1:spdxId <https://spdx.org/> .

ns1:NoAssertionElement a owl:NamedIndividual,
        ns1:Element ;
    rdfs:comment """An Individual Value for Element representing a set of Elements of unknown
identify or cardinality (number)."""@en ;
    ns1:creationInfo _:_CreationInfo .

ns1:NoneElement a owl:NamedIndividual,
        ns1:Element ;
    rdfs:comment """An Individual Value for Element representing a set of Elements with
cardinality (number/count) of zero."""@en ;
    ns1:creationInfo _:_CreationInfo .

ns7:NoAssertionLicense a owl:NamedIndividual,
        ns7:IndividualLicensingInfo ;
    rdfs:comment """An Individual Value for License when no assertion can be made about its actual
value."""@en ;
    owl:sameAs <https://spdx.org/rdf/3.0.1/terms/Licensing/NoAssertion> ;
    ns1:creationInfo _:_CreationInfo .

ns7:NoneLicense a owl:NamedIndividual,
        ns7:IndividualLicensingInfo ;
    rdfs:comment """An Individual Value for License where the SPDX data creator determines that no
license is present."""@en ;
    owl:sameAs <https://spdx.org/rdf/3.0.1/terms/Licensing/None> ;
    ns1:creationInfo _:_CreationInfo .

_:_CreationInfo a ns1:CreationInfo ;
    ns1:created "2024-09-13T00:00:00Z"^^xsd:dateTimeStamp ;
    ns1:createdBy ns1:_SpdxOrganization ;
    ns1:specVersion "3.0.1"^^xsd:string .

[zvr]

No, this is not the right way to add the SPDX Individual Organization.

It should be added to the model / Core / Individuals.

And please use spdx.org for its id.

[bact]

Does it mean it is possible for the user to use the _SpdxOrganization individual?

[bact]

The intention of the current code is to hide the _SpdxOrganization from the public spec documentation. This is also partly reflected in the naming by using a prefix _.

But if we like to advertise the _SpdxOrganization (probably with a new name "SpdxOrganization") in the public spec, can remove that part of the code from this PR and add the SpdxOrganization in spdx-3-model instead.

Update: if we will go for that route, these two PRs are needed:

• Add /Core/Individuals/SpdxOrganization spdx-3-model#880
• Process "Property values" for named individuals #155 (to process the SpdxOrganization)
• and then update this PR

[zvr]

@bact, please don't spend time implementing stuff without first having reached consensus on how this should be done. I feel bad seeing all this work implementing alternatives where only one of them will be merged...

To your points:

• we will have an individual referring to the SPDX organization in our model
• the RDF generation of all individuals will be using this (hard-wired as creator)

But please, ignore the spec-parser code and don't make any PRs.
Due to tomorrow's deadline I will not be merging anything (since it might not match what I am currently using). I will be doing any necessary changes to whatever I have and I will push these sometime next week.

[bact]

Thank you for review. I sometimes have hard time to describe what I have in my mind, so some code can help myself saying it more concretely and hopefully help others well, for them to decide if the idea is a no or a go or something needs to be revise. Please reject things that doesn't make sense or not fit into the time frame.

• I have removed the _SpdxOrganization from this PR (to use one in the model)
• Retain the hard-wired CreationInfo here

Understand your point on deadline. Feel free to close this PR if you already implemented it.

[goneall]

Just FYI - @JPEWdev is investigating an alternative approach where we separate the ontology from the SHACL. It looks like if we do this, the validation will pass since the individual definitions will be in the OWL document.

This alternative approach would require some changes to some of our code generation tools, but may be a cleaner approach.

[sbarnum]

The identifier for the creationInfo needs to be more than simply "_:CreationInfo".
It needs to be specific to the particular release (something like ":v3.0.1CreationInfo",
In future versions of SPDX there may be multiple different predefined named individuals that were defined in different releases. Their creationInfo details need to be kept distinct and integrous.
A future version 3.1.0 would keep the ":v3.0.1CreationInfo" (and its use within predefined named individuals defined in 3.0.1) and add a new ":_v3.1.0CreationInfo" to be used by any new predefined named individuals if there are any added in 3.1.0.

[sbarnum]

Just FYI - @JPEWdev is investigating an alternative approach where we separate the ontology from the SHACL. It looks like if we do this, the validation will pass since the individual definitions will be in the OWL document.

This alternative approach would require some changes to some of our code generation tools, but may be a cleaner approach.

I would recommend against separating the SHACL from the OWL. While this is valid to do, it does NOT solve the underlying issue in play here (whether the OWL and SHACL are combined as currently done or separated, if you want to validate the type of a predefined named individual that is an Element you will still need to define creationInfo for it; separating the OWL and SHACL does nothing to resolve this issue) and it only makes it more complex to manage the coordinated evolution of the OWL and SHACL.

[JPEWdev]

@sbarnum Splitting the files is (AFAICT) the expected way that the validation tools handle this. They all(?) allow separate aregument for the shapes graph vs the ontology, where objects in the shapes graph are are validated, but objects in the ontology are not validated.

Splitting the shapes and ontology graphs into separate files is going to be the cleanest solution that aligns with the validation tools, and we can still easily generate a combined "model" graph if that is what OMG needs (I'm not sure if they care about the shape graph or not)

[JPEWdev]

Nevermind. After playing around a little, I think I misunderstood what the validation tools were doing, so we probably need to add the creationinfo

[bact]

The identifier for the creationInfo needs to be more than simply "_:CreationInfo". It needs to be specific to the particular release (something like ":v3.0.1CreationInfo", In future versions of SPDX there may be multiple different predefined named individuals that were defined in different releases. Their creationInfo details need to be kept distinct and integrous. A future version 3.1.0 would keep the ":v3.0.1CreationInfo" (and its use within predefined named individuals defined in 3.0.1) and add a new ":_v3.1.0CreationInfo" to be used by any new predefined named individuals if there are any added in 3.1.0.

@sbarnum would you recommend

1. _:_V3_0_1_CreationInfo or
2. _:_CreationInfoV3_0_1 ?

(We cannot use . inside the name)

Also would you mind to take a look at the SpdxOrganization individual PR please?

• Add /Core/Individuals/SpdxOrganization spdx-3-model#880

[bact]

The identifier for the creationInfo needs to be more than simply "_:CreationInfo".
It needs to be specific to the particular release (something like ":_v3.0.1CreationInfo",

PR updated: 3.0.1's CreationInfo is now _:_V3_0_1_CreationInfo.

In future versions of SPDX there may be multiple different predefined named individuals that were defined in different releases. Their creationInfo details need to be kept distinct and integrous.
A future version 3.1.0 would keep the "_:v3.0.1CreationInfo" (and its use within predefined named individuals defined in 3.0.1) and add a new ":_v3.1.0CreationInfo" to be used by any new predefined named individuals if there are any added in 3.1.0.

With this requirement that @sbarnum suggested. We may need to have information inside the model file about which version of SPDX that a particular individual is introduced in? @goneall @zvr @JPEWdev @ilans

Something along this line?

# NoneLicense

## Metadata

- name: NoneLicense
- type: IndividualLicensingInfo
- IRI: https://spdx.org/rdf/3.0.0/terms/Licensing/None
- sinceVersion: 3.0.0

(note the difference between the version number in sinceVersion and in IRI)

# SpdxOrganization

## Metadata

- name: SpdxOrganization
- type: Organization
- IRI: https://spdx.org/
- sinceVersion: 3.0.1

# ExampleOrganization

## Metadata

- name: ExampleOrganization
- type: Organization
- IRI: https://example.com/
- sinceVersion: 3.1.0

The sinceVersion name is found being use in API specs, together with untilVersion to signal support; see for examples at MS SQL Server, IntelliJ, Square Wire.

But this approach means we may need to add something to the model (sinceVersion as a new property?), which may not be desirable at this stage.

These information can be alternatively hard coded inside the spec-parser as well, but that means there will be few information about the model that is not transparently documented and version controlled inside spdx-3-model repo.

(We may even need to have a creation datetime recorded somewhere as well for each version, because we need that datetime information to recreate a CreationInfo instance for a particular version. The creation datetime of 3.0.1 will be different from 3.1. If we do not record the creation datetime of 3.0.1 somewhere, we might not be able to recreate the exact copy of 3.0.1's CreationInfo when we move to 3.0.2/3.1. One way is to record the entire CreationInfo instance, which will include both spec version and creation datetime).

In any case, the current implementation purposed by this PR will not work in the future because it assumes that all the individuals will have the same CreationInfo, which is not true if we have a new individual introduced in any next version. The code in this PR needs revision or another PR has to be created to replace this one.

[zvr]

I've implemented a simpler patch for this, in #159

[bact]

Close after email discussions and a separate tech call on 2024-12-05. Please look at PR #159 instead.