Another alternative is to just use a guid by itself as a URI - e.g.: urn:uuid:3F2504E0-4F89-41D3-9A0C-0305E82C3301. Less readable, but unique.
Agreed. I like the idea of having a human readable portion re http://spdx.org/spdxdocs/3F2504E0-4F89-41D3-9A0C-0305E82C3301-spdx-tools-v1.2 I'm also wondering if we should switch and have the human readable portion first, e.g. http://spdx.org/spdxdocs/spdx-tools-v1.2-3F2504E0-4F89-41D3-9A0C-0305E82C3301 Note: spdx.org spdxdocs will not be accessible on the website. Hmmm.. What if it were? I suppose there are lots of potential issues on that but would it be interesting enough to consider? Jack -----Original Message----- From: Gary O'Neall [mailto:[email protected]] Sent: Friday, April 04, 2014 2:38 PM To: 'Bill Schineller'; Manbeck, Jack; 'Nuno Brito' Cc: [email protected] Subject: RE: proposed language for referencing element in one SPDX document from another Thanks Bill for pulling this together. Should we prescribe how the unique identifiers are built in the RDF document to make it easier to translate between tag/value and RDF? If so, I added some proposed language inline below. There may also be a case where someone is producing an SPDX doc and they are not part of an organization which has a unique namespace. I'm not sure if this would really be an issue, but we could come up with a naming scheme for that situation using spdx.org domain. For example: If the producing person is not part of an organization which has a unique basename, the following basename can be use: http://spdx.org/spdxdocs/[guid]-[packageVersionid] where packageVersionid is a human readable name that describes the content of the SPDX document and guid is a generated version 4 globally unique ID. A new GUID would be generated for each document. Example: http://spdx.org/spdxdocs/3F2504E0-4F89-41D3-9A0C-0305E82C3301-spdx-tools-v1. 2 Note: spdx.org spdx docs will not be accessible on the website. Another alternative is to just use a guid by itself as a URI - e.g.: urn:uuid:3F2504E0-4F89-41D3-9A0C-0305E82C3301. Less readable, but unique. Gary > -----Original Message----- > From: [email protected] [mailto:spdx-tech- > [email protected]] On Behalf Of Bill Schineller > Sent: Thursday, April 3, 2014 7:03 AM > To: Manbeck, Jack; Nuno Brito > Cc: [email protected] > Subject: RE: proposed language for referencing element in one SPDX > document from another > > Hi Nuno, Jack, all - > > I agree with Jack. How does the extra Note I added below sound? > - Bill > > > Producers of SPDX data are expected to 'own' a namespace for their > organization. (e.g. 'http://acme.com/spdx') > > When releasing an SPDX document for external consumption, its basename > must be unique within the namespace of the producing organization. > (e.g. http://acme.com/spdx/mypackage-1-2.spdx where the organization > will not distribute another modified file with same basename > 'mypackage-1-2.spdx' ) > > [Note: Establishing a 'namespace of the producing organization' does > not necessarily imply/require that SPDX documents get posted publicly > on the internet. An organization could confidentially share SPDX > documents it produces with partners. Regardless, the producing > organization should uniquely identify itself as with a namespace it > 'owns' (e.g. "http://acme.com/spdx";). > SPDX documents it distributes (whether over the internet or in a > folder of some archive/container transmitted privately) should have > unique basenames within the namespace / realm of every SPDX document > the producing organization has ever distributed. Inside each > distributed SPDX document, the namespace of the producing organization > will be part of the unique id of the 'SPDXDocument' element (e.g. the > leading part of 'http://acme.com/spdx/mypackage-1-2.spdx'). The > consumer of the SPDX document shouldn't expect that the document will > be available at a publicly accessible URL > 'http://acme.com/spdx/mypackage-1-2.spdx', and in the case that it is > not, the consumer should keep a copy of the SPDX document it received locally > at a sensibly named location (e.g. > '/myspdxcache/spdx/com/acme/mypackage-1-2.spdx). The SPDX spec does > not prescribe how consumed SPDX docs are handled locally, so consumers > should take care to keep docs they received in a location they can be > found internally. > ] > > > [Note: if the organization subsequently releases an update to their > SPDX analysis for same package, the updated document must carry a new, > unique basename, e.g. 'mypackage-1-2-rev1.spdx'] > > [Note: best practice is to use the .spdx suffix on all SPDX documents, > regardless of tag-value or RDF format] > > Additionally, an accompanying file with the SHA-1 hash of the file > should sit alongside it, named the same, plus the extension .sha1 > (e.g. 'http://acme.com/spdx/mypackage-1-2.spdx.sha1' The contents of > the .sha1 file is a single line with the sha1 of the published .spdx > file.) > > Within the SPDX document, each SPDXElement (including subclasses) > shall be assigned a unique id (unique within the scope of the > document.) For tag-value format, each field shall have an SPDXRef-[idString] with a unique identifier for each element. In RDF format, the unique id is the resource URI identified formed by the SPDX document URI concatenated with #SPDXRef-[idSTring]. > [Note: for tag-value format, this means populating the field SPDXRef- > [idString] with a unique identifier for each element. In RDF format, > the unique id is the resource URI identifier.] > > > > > ________________________________________ > From: Manbeck, Jack [[email protected]] > Sent: Thursday, April 03, 2014 9:13 AM > To: Nuno Brito; Bill Schineller > Cc: [email protected] > Subject: RE: proposed language for referencing element in one SPDX > document from another > > Hi Nuno, > > As far as I understand it using a company web address does not > necessarily mean the document is available over the Internet. It's > just a way to provide uniqueness. We are also looking at providing a > default name space at spdx.org but that would require use of a UID in > case someone did not have domain name. > > Jack > > > -----Original Message----- > From: [email protected] [mailto:spdx-tech- > [email protected]] On Behalf Of Nuno Brito > Sent: Thursday, April 03, 2014 8:18 AM > To: Bill Schineller > Cc: [email protected] > Subject: Re: proposed language for referencing element in one SPDX > document from another > > Hi Bill, > > The proposed approach is useful. I will try it out in practice. > > Just have one question in regards to: > > When releasing an SPDX document for external consumption, its > basename > > must be unique within the namespace of the producing organization. > > (e.g. http://acme.com/spdx/mypackage-1-2.spdx where the > > organization will not publish another file with basename > > 'mypackage-1-2.spdx' ) > > I have cases where the document is included on the distribution > package but where the owners are not willing to make it available to > public (just privately to selected companies). > > Meaning, a network location isn't possible as namespace. I'm currently > referring to other SPDX documents within the folder structure as > solution. > > To keep the URI scheme possible and reference documents within the > folders, would something like this be possible? > > file:///./spdx/mypackage-1-2.spdx > > Or perhaps I misunderstood the intention of namespaces. My thanks in > advance. > > > With kind regards, > Nuno Brito > > --- > email: [email protected] > phone: +49 615 146 03187 > > _______________________________________________ > Spdx-tech mailing list > [email protected] > https://lists.spdx.org/mailman/listinfo/spdx-tech > _______________________________________________ > Spdx-tech mailing list > [email protected] > https://lists.spdx.org/mailman/listinfo/spdx-tech _______________________________________________ Spdx-tech mailing list [email protected] https://lists.spdx.org/mailman/listinfo/spdx-tech
