Looks good to me! I second the point on having proper namespaces - i.e. in the cve example, it feels like it could easily be overloaded. It may also provide some context to help in validating provenance at a later point.
On Tue, May 10, 2022 at 9:49 AM David Kemp <[email protected]> wrote: > @William, That sounds reasonable, but it doesn't solve the problem of > "Actor". If an Element is createdBy one Identity and Identity has > Person/Organization/(tool?) subclasses, then there is no way to express > that an Element was createdBy a person acting on behalf of an organization > vs. the same person acting individually. And defining Element as created > by 1..* Identities is a huge mess, including how to authenticate each of > them. > > I like "identifiedBy" identifier properties, but I think each identifier > should be tagged as person/organization/(tool?) rather than subclassing the > Identity/Actor Element. > > > @Jeff, what problem does the defects group perceive as resulting from not > explicitly labeling a difference between URLs and URIs? The 2002 > "contemporary view" of https://www.rfc-editor.org/rfc/rfc3305#section-2.2 > still seems applicable today: >> >> The term "URL" does not refer to a formal partition of URI space; rather, >> URL is a useful but informal concept. > > > URIs can refer to both "information resources" and "non-information > resources" like namespaces ( > http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#note-informationResource). > Non-information resources can never be located, while URIs for information > resources can be persistent identifiers, temporary locators, or both. > > One argument for not creating an artificial dichotomy is that any > non-locator URI becomes a locator as soon as anyone deploys a resolver > service, and that such resolvers are used in practice to locate namespaced > information resources using SPARQL. > > So I would ask about a proposal to define separate property names: what > problem does it solve? > > Regards, > Dave > > On Mon, May 9, 2022 at 11:34 PM Jeff Schutt (jefschut) via lists.spdx.org > <[email protected]> wrote: > >> Hey William, >> >> >> >> Initial reactions: >> >> - I like the simplicity this introduces wrt consolidating various >> types of identifiers in the model. >> - I don’t like that this continues to co-mingle identifiers and >> locators, and perpetuates some of the confusion caused by the way >> ExternalReferences are defined in v2.x. >> >> >> >> Two observations of previous SPDX decisions made: >> >> 1. The 3.0 model uses “ArtifactURI” rather than the subset of >> “ArtifactURL” >> 2. In the Defects WG we accepted this identifier/locator co-mingling >> as part of the patch to v2.3 with the expectation that we would resolve it >> by ensuring identifiers and locators are separate entities in v3.0. >> >> >> >> How would you suggest accommodating this separation in the proposal? >> >> >> >> One option would be to have “identifiedBy” and “locatedBy” both be on >> “Element”. >> >> >> >> { >> >> "SPDXID": "urn:spdx.dev:spdx-tools-3.0.0", >> >> "name": "spdx-tools-3.0.0", >> >> "locatedBy": [ >> >> {"type": "PURL", "locator": "pkg:..."} >> >> ], >> >> "identifiedBy": [ >> >> {"type": "cpe22", "identifier": "..."}, >> >> {"type": "SWHID", "identifier": "..."} >> >> ] >> >> } >> >> >> >> >> >> - Jeff >> >> >> >> *From: *<[email protected]> on behalf of "William Bartholomew >> (CELA) via lists.spdx.org" <[email protected]> >> *Reply-To: *"[email protected]" <[email protected]> >> *Date: *Monday, May 9, 2022 at 8:00 PM >> *To: *spdx-tech <[email protected]> >> *Subject: *[spdx-tech] Simplifying Identities >> >> >> >> I experimented with something around identities and I'm really liking the >> simplicity, so I wanted to run it by you to get your thoughts: >> >> - We keep "Identity" element with subclasses of "Person" and >> "Organization" (I'm ignoring "Tool" for right now). >> - Introduce a new data type "Identifier" which could have subtypes >> like "EmailAddress" and "Login". >> - Add a property to "Element" called "identifiedBy" which is a list >> of zero or more "Identifier". >> >> This means we can have a Person that looks like this: >> >> >> >> { >> >> "SPDXID": "urn:github.com:users:iamwillbar", >> >> "type": "Person", >> >> "name": "William Bartholomew", >> >> "identifiedBy": [ >> >> {"type": "EmailAddress", "email": "[email protected]"}, >> >> {"type": "Account", "authority": "github.com", "username": >> "iamwillbar"} >> >> ] >> >> } >> >> >> >> This then got me thinking that "artifactUrl" on "Artifact" is just >> another form of "Identifier", which means we could remove that property and >> so a "Package" could look like this: >> >> >> >> { >> >> "SPDXID": "urn:spdx.dev:spdx-tools-3.0.0", >> >> "name": "spdx-tools-3.0.0", >> >> "identifiedBy": [ >> >> {"type": "PURL", "locator": "pkg:..."} >> >> ] >> >> } >> >> >> >> What does that remind you of? "ExternalReferences", so we can then remove >> those and merge that concept into identifiers: >> >> >> >> { >> >> "SPDXID": "urn:spdx.dev:spdx-tools-3.0.0", >> >> "name": "spdx-tools-3.0.0", >> >> "identifiedBy": [ >> >> {"type": "PURL", "locator": "pkg:..."}, >> >> {"type": "cpe22", "locator": "..."}, >> >> {"type": "SWHID", "locator": "..."} >> >> ] >> >> } >> >> >> >> And because "identifiedBy" is on "Element" any new types we add in the >> future can also have identifiers attached to them: >> >> >> >> { >> >> "SPDXID": "urn:cve:12345", >> >> "name": "tkvideo has a memory issue in playing videos", >> >> "identifiedBy": [ >> >> {"type": "CVE", "locator": "CVE-2022-24902"} >> >> ] >> >> } >> >> >> >> What do you all think? >> >> >> >> Sent from Outlook <http://aka.ms/weboutlook> >> >> > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#4498): https://lists.spdx.org/g/Spdx-tech/message/4498 Mute This Topic: https://lists.spdx.org/mt/91005596/21656 Group Owner: [email protected] Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
