Specifying/Specialising the 'from' and 'to' in some relationship type descriptions

[bact]

In 3.0/3.1-dev, few relationship type descriptions don't explicitly specified type of their 'from'/'to'. There are also some 'to's that could be more specialised/clarified.

Please see the tables below and the "Notes" in the last column for questions / suggestions.

• The Table 1 has higher priority and the specification of type may not considered as a breaking change (as it has never been specified).
• Some proposed changes in Table 2 however may or may not be considered a breaking change, depends on interpretation.

Table 1: 'from'/'to' is not typed

relationshipType	from	to	Description	Notes
expandsTo	"archive"	Element	"The from archive expands out as an artifact described by each to Element."	'from' is not explicitly typed. Should it be a SoftwareArtifact, with primaryPurpose = "archive" ? -- PR #1123
hasConcludedLicense	SoftwareArtifact	"license"	"The from SoftwareArtifact is concluded by the SPDX data creator to be governed by each to license."	'to' is not explicitly typed. Should it be an AnyLicenseInfo? Or it can also be a URL to https://spdx.org/licenses/xx? (but that should also be specified?) -- PR #1122
hasDeclaredLicense	SoftwareArtifact	"license"	"The from SoftwareArtifact was discovered to actually contain each to license, for example as detected by use of automated tooling."	'to' is not explicitly typed. Should it be an AnyLicenseInfo? Or it can also be a URL to https://spdx.org/licenses/xx? -- PR #1122

Table 2: 'to' could be more specialised

Some proposed changes in here may or may not be considered a breaking change, depends on interpretation.

For example, in the description of hasAddedFile, it current reads

Every to Element is a file added to the from Element.

If it is amended to

Every to is a File added to the from Element.

would it be considered a type change (= breaking) or a mere textual clarification (= non-breaking)?

relationshipType	from	to	Description	Notes
hasAddedFile	Element	Element	"Every to Element is a file added to the from Element"	Should 'to' be a File?
hasDataFile	Element	Element	"The from Element treats each to Element as a data file."	Should 'to' be a File? Or File + DatasetPackage ? Or SoftwareArtifact (superclass of File and DatasetPackage) ?
hasDeletedFile	Element	Element	"Every to Element is a file deleted from the from Element"	Should 'to' be a File?
hasDependencyManifest	Element	Element	"The from Element has manifest files that contain dependency information in each to Element."	Should 'to' be a File with primaryPurpose = "manifest" ?
hasDistributionArtifact	Element	Element	"The from Element is distributed as an artifact in each to Element (e.g. an RPM or archive file)."	Should 'to' be an Artifact?
hasTest	Element	Element	"Every to Element is a test artifact for the from Element"	Should 'to' be an Artifact?
packagedBy	Element	Element	"Every to Element is a packaged instance of the from Element"	Should 'to' be a Package?

(Excerpt from this full sketch of 3.1-dev RelationshipType)

[goneall]

I think specializing to a type is fine - agree that these should not be breaking changes - even the additional restrictions in the second table is OK IMHO.

I would not add an additional restriction on any other fields since they are optional - adding the restriction would make them required which would be a breaking change.

[bact]

Agree on not having specific property value as a requirement (for example, primaryPurpose) as there can be a case that an element is built for one thing but it is used (by the 'from') for another thing.