Hi Robin,

Got a chance to read through the document.  Thanks for clearly laying out the issues with representing aggregated projects in SPDX - I think this is a good problem to solve for the general community and once we're done, I would like to include this in the SPDX best practices document (minus the DoSOCS specifics) if that is OK with you.

A couple high level points and feedback:

·         In general, I agree with the approach.

·         For Maven, you can map the Maven dependency scope to the SPDX relationship type.  You can see what I chose as mapping in the Java method scopeToRelationshipType in the SpdxDependencyInformation.java file.  If you see anything you disagree with - do me a favor and log an issue in the Git repository.

·         I would only use PACKAGE_OF if the included package is compiled in source as a sub-project (e.g. a subdirectory) or if it is a complete independent package being distributed as part of a larger distribution.  In a Maven POM file, they are likely dymaically linked dependencies.  From the PDF document, I wasn't sure of the specifics on the example - but they kind of looked liked dynamically linked dependencies.

·         Definition of Package, Application and Project - Here's the definition of a package from the RDF terms:  " A Package represents a collection of software files that are delivered as a single functional component. "  Would this definition apply to Project (e.g. the "files" would be the metadata files)?  We should consider adding this definition to the PDF specification to be consistent (or re-discussing the definition if any disagrees with the RDF definition).  I think it would be useful to define certain types of packages for the use in best practices (e.g. simple packages containing only source files, complex packages including dependency specifications, project packages which only contain metadata files, etc.).

Gary