My action item last week, short descriptions of 5 relationships in my  java / 
jar re-use diagram

1)
builtFrom (Shared libraries, source code files and other files needed to build 
the binary file)
[I'm regurgitating Sameer's description]

2)
artifactOf (general pointer to a external package identifier, e.g. Maven GAV or 
SPDXElement that an SPDXElement came from)

3)
patchOf (point to an SPDXElement that this set of SPDXElement is a patchOf, by 
adding, removing, or replacing files)

4)
upstreamBinary  (point to an SPDXFile(type=binary) in an external SPDXDocument 
that  SPDXFile(type=binary) is the same as)

5)
burst  (for archives, unpacking the contents within…)
[Bill alternatively nicknamed this 'expanded']

6)
patchApplied (points from an SPDXDocument of a codebase with the referenced 
patch applied, to the SPDXDocument describing the patch)
[Bill previously nicknamed this 'exploded']



________________________________
From: [email protected] [[email protected]] on 
behalf of Gary O'Neall [[email protected]]
Sent: Friday, April 04, 2014 1:23 PM
To: [email protected]
Subject: Usage and Relationship Enumerations

Follow up to the tech call - my action to send out one line descriptions for 
usage types.


Here's a proposal for one line descriptions for the list of usage and 
relationship enumerations that we came up with at Linux Con:.  For consistency 
with enumerations in the 1.2 spec, I pre-pended "relationshipType_" and 
"usageType_" before relationship and usage enumerations resp.  I also included 
some comments in "[]".


relationshipType: Describes the type of relationship between two SPDX elements.

·         relationshipType_partOf: The relatedSpdxElement is a part of this 
SpdxElement but not contained within it [NOTE: do we need both partOf and 
contained?].

·         relationshipType_contains: The relatedSpdxElement is a contained 
within this SpdxElement [NOTE: do we need both partOf and contained?].

·         relationshipType_generatedFrom: The relatedSpdxElement generates this 
SpdxElement.  The generation can be any form of transformation where the 
relatedSpdxElement is an input to the transformation and this SpdxElement is an 
output.  Examples: compilation, linking.

·         relationshipType_modifies: This SpdxElement is a modified version of 
the relatedSpdxElement. [Note: Not sure if this is the meaning or if the 
relatedSpdxElement performs some sort of modification function like 
generatedFrom]

·         relationshipType_modifiedBy: The relatedSpdxElement is a modified 
version of this SpdxElement. [Note: Not sure if this is the meaning or if the 
SpdxElementperforms some sort of modification function like generates]

·         relationshipType_revisionOf: The relatedSpdxElement is a revision of 
this SpdxElement. [Note: Do we need revisionOf and the modified types?]

Usage:

·         usageType_source: The relatedSpdxThing is a source file used to 
compile a resultant executable.

·         usageType_executable: The relatedSpdxThing is an independent 
executable binary file executed by this SpdxElement.

·         usageType_dynamicLibrary: The relatedSpdxThing is an binary library 
file which is dyamically linked to this SpdxElement.

·         usageType_staticLibrary: The relatedSpdxThing is an binary library 
file which is statically linked to this SpdxElement.

·         usageType_dataFile: The relatedSpdxThing is an data file used by this 
SpdxElement.

·         usageType_test: The relatedSpdxThing is a file (data, source, 
executable or other file type) used only in the testing by this SpdxElement.

·         usageType_buildTools: The relatedSpdxThing is a tool used only in the 
building by this SpdxElement.

·         usageType_documentation: The relatedSpdxThing is documentation for 
this SpdxElement.

·         usageType_optional: The relatedSpdxThing is an optional element for 
this SpdxElement. Optional elements may or may not be included in the 
distributed package. Examples include contrib libraries, optional debugging 
facilities.

·         usageType_referenceImpl: The relatedSpdxThing is a reference 
implementation for this SpdxElement.

-------------------------------------------------
Gary O'Neall
Principal Consultant
Source Auditor Inc.
Mobile: 408.805.0586
Email: [email protected]<mailto:[email protected]>

_______________________________________________
Spdx-tech mailing list
[email protected]
https://lists.spdx.org/mailman/listinfo/spdx-tech

Reply via email to