Dear all,
I thought that would be helpful to summarise the recent discussions
about identifiers for Elements in the upcoming SPDX 3.0 specification.
There were four different options put forward, which I described in a
file on GitHub (and which I've also attached to this email):
https://gist.github.com/seabass-labrax/b05cafa72cecae661fc0067d3a0d242d
Option 2 had the disadvantage that it would have required SPDX to define
a special character to delimit the prefix and suffix part of the URI.
Option 3 (which I had initially supported for its suitability for use in
relational databases) was unsuitable for use in Linked Data formats such
as JSON-LD and RDF/XML, as these use atomic identifiers which cannot
hold compound values. As such, converting between Linked Data and other
formats would result in loss of data.
Option 4 improves upon Option 3 to make it compatible with Linked Data
formats, but would run the risk of having the defined namespace
inconsistent with the URI's actual prefix substring.
Ultimately, therefore, I think Option 1 was the generally accepted form
for Element identifiers - a single URI, which does not semantically
distinguish a namespace from a local part, and which can be shortened in
the serialisation if a prefix that is common to multiple elements can be
found.
Please do respond to this email if I've missed anything! I look forward
to hearing from you at today's meeting :)
Best wishes,
Sebastian
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4214): https://lists.spdx.org/g/Spdx-tech/message/4214
Mute This Topic: https://lists.spdx.org/mt/86096739/21656
Group Owner: [email protected]
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
## OPTION 1
```json
{
"id": "systemd-v249-files-Makefile-v1",
"specVersion": "3.0",
"elementType": "file",
"fileType": "source",
"artifactUrl": "https://github.com/systemd/systemd/blob/v249/Makefile";
}
```
Note that the Element must have either a full URI as a String in its `id` property or be within a collection element which has a namespace property. In the latter case, the `id` of the Element is appended to the end of the collection's namespace to form the full URI.
## OPTION 2
```json
{
"id": "spdx://bigcompany.org/systemd-v249-files-Makefile-v1",
"specVersion": "3.0",
"elementType": "file",
"fileType": "source",
"artifactUrl": "https://github.com/systemd/systemd/blob/v249/Makefile";
}
```
The entire URI is always a String inside the Element.
## OPTION 3
```json
{
"id":{
"suffix": "/systemd/v249/files/Makefile/v1",
"prefix": "spdx://bigcompany.org"
},
"specVersion": "3.0",
"elementType": "file",
"fileType": "source",
"artifactUrl": "https://github.com/systemd/systemd/blob/v249/Makefile";
}
```
The full URI is always inside the Element, as a compound type of two strings (the first being namespace and the second being the local part of the ID).
## OPTION 4
```json
{
"id": "spdx://bigcompany.org/systemd/v249/files/Makefile/v1",
"namespace": "spdx://bigcompany.org",
"specVersion": "3.0",
"elementType": "file",
"fileType": "source",
"artifactUrl": "https://github.com/systemd/systemd/blob/v249/Makefile";
}
```
The full URI is always inside the Element as a single String. There is another property in the Element, `namespace`, which defines the namespace which the Element is part of. The onus is on the producer of the SPDX data to ensure that `namespace` really is a prefix of `id`.
