Just in case, there's a lot of homonymies in naming software projects, so the "short name" may not be sufficient.

The URL of the homepage of a project may be better, but sometimes projects move, so this may be variable.

Automatic matching of harvested data may not be trivial. Note that there's relevant litterature on the topic : http://www.igi-global.com/chapter/integrating-projects-multiple-open-so… (DOI: 10.4018/jossp.2009010103 )

Multi-domain identifiers may lead to naming conflicts. Within one domain we may assume that a shortname for a software project is unique, but within different domains, we cannot, unless we use a URI or IRI of course. 

To allow multiple identification domains, version 0.3 hasa data type Identifier that stems from the Identifier. Type of the UN/CEFACT Core Components Data Type Catalogue v3.1 . It has the following properties:

 

• Content: String [1..1] A character string used to uniquely identify one instance of an object within an identification scheme that is managed by an agency.
• SchemeIdentifier: String [0..1] The identification of the identifier scheme.
• SchemeVersion: String [0..1] The identification of the version of the identifier scheme
• SchemeAgency: String [0..1] The identification of the agency that manages the identifier scheme 

 

 

Tthe ISO/IEC 19770-2:2009 standard and the corresponding XML schema define the following structure to identify a software package:

<xs:complexType name="SoftwareIdComplexType">

<xs:sequence> <xs:element name="unique_id" type="swid:Token"/> <xs:element name="tag_creator_regid" type="swid:RegistrationId"/> </xs:sequence> <xs:attributeGroup ref="swid:default"/> </xs:complexType>   The following XML snipped in an example for the Adobe X pro product:   <swid:software_id> <swid:unique_id>AcrobatPro-AS1-Win-GM-MUL</swid:unique_id> <swid:tag_creator_regid>regid.1986-12.com.adobe</swid:tag_creator_regid> </swid:software_id

 

 

The SPDX specification uses URIs / IRIs to identify software packages (spdx:Package). Because the vocabulary is an RDF vocabulary these URIs are implicit to the specification.

The SPDX example file: http://www.spdx.org/system/files/spdxspreadsheetexample.rdf_.txt includes an example of such a URI: http://www.spdx.org/tools#SPDXANALYSIS?package

 

<Package rdf:about="http://www.spdx.org/tools#SPDXANALYSIS?package"> <licenseDeclared> <ConjunctiveLicenseSet> <member> <License rdf:about="http://spdx.org/licenses/MPL-1.1"> <licenseId>MPL-1.1</licenseId> </License> <packageDownloadLocation>http://www.spdx.org/tools</packageDownloadLocation> <hasFile> <File> <copyrightText>Copyright 2010, 2011 Source Auditor Inc.</copyrightText> <licenseComments></licenseComments> <licenseInfoInFile rdf:resource="http://spdx.org/licenses/Apache-2"/> <licenseConcluded rdf:resource="http://spdx.org/licenses/Apache-2"/> <fileType>SOURCE</fileType> <checksum> <Checksum> <checksumValue>2fd4e1c67a2d28fced849ee1bb76e7391b93eb12</checksumValue> <algorithm>SHA1</algorithm> </Checksum> </checksum> <fileName>src/org/spdx/parser/DOAPProject.java</fileName> </File> </hasFile> <licenseInfoFromFiles rdf:nodeID="A3"/> <checksum> <Checksum> <checksumValue>2fd4e1c67a2d28fced849ee1bb76e7391b93eb12</checksumValue> <algorithm>SHA1</algorithm> </Checksum> </checksum> <sourceInfo>Version 1.0 of the SPDX Translator application</sourceInfo> <packageVerificationCode> <PackageVerificationCode> <packageVerificationCodeValue>4e3211c67a2d28fced849ee1bb76e7391b93feba</packageVerificationCodeValue> <packageVerificationCodeExcludedFile>SpdxTranslatorSpdx.txt</packageVerificationCodeExcludedFile> <packageVerificationCodeExcludedFile>SpdxTranslatorSpdx.rdf</packageVerificationCodeExcludedFile> </PackageVerificationCode> </packageVerificationCode> <packageFileName>spdxtranslator-1.0.zip</packageFileName> <description>This utility translates and SPDX RDF XML document to a spreadsheet, translates a spreadsheet to an SPDX RDF XML document and translates an SPDX RDFa document to an SPDX RDF XML document.</description>

The checksum (spdx:Checksum) and verification code (spdx:PackageVerificationCode) can be used to authenticate a pacakge, but is unpractical (because meaningless to humans) to identify it or use it to mint a URI.

The approach of  ISO/IEC 19770-2:2009 that you mentioned implies the use of a central registry. That may be needed when there are trust issues. But I'm not sure that's a problem in the current use cases ADMS.F/OSS has collected.

That's a totally different approach that that of the Semantic Web / Linked Data, which basically relies on URI which may be chosen at random. Only dereferencing them and checking for the contents, and some kind of web of trust (based on the underlying confidence in the DNS system) loosely guarantees desambiguation.

I myself would prefer putting the second one (Linked Data's) forward to maximize adoption without the hassles of managing a central authority, while controlled unique IDs may be added by services using ADMS.F/OSS if they wish and need some enhanced trust mechanism.

ADMS.SW v1.00 has a two identification mechanisms other than URIs:

• the adms:Identifier class (based on  UN/CEFACT Core Components Data Type Catalogue v3.1 )
• the swid:SoftwareId class (based on ISO/IEC 19770-2:2009)