Today's discussion of the Identity model was very interesting.  A few
thoughts:

* Entity resolution (e.g.,
https://www.ibm.com/docs/en/iii/9.0.0?topic=insight-entity-resolution) is
an enormously complex process.  Casinos have a business interest in knowing
that a person is not acting under multiple identities for fraudulent
purposes; linking voter registration rolls to strongly identity-proofed
RealID drivers licenses is another example.

* SPDX has no use case (that I'm aware of) for doing any kind of entity
resolution - ensuring that the same person is not using more than one SPDX
Identity.  Artifacts are scanned for whatever person identifiers (name and
email) are present, and the results recorded in the SPDX Document. If one
person has 4 different email addresses, it is not SPDX's role to discover
that they are actually a single person.  And it's a given that with 330
million U.S. persons, name collisions (multiple meatbags having the same
first and last name) are inevitable.  SPDX doesn't care, it's just
harvesting what the scanners see.

* With regard to inheritance, I'm in the database graph camp - the simplest
way for SPDX to both perform its own functions and integrate into the
larger world is to be as simple as possible - Person is a type all by
itself, not a subclass of Identity which is in turn a subclass of Element.
An SPDX document can list all the Person instances it sees, with whatever
fields are interesting about a person - so far, just email address (primary
key) and name.  Adding an SPDX-Ref or a comment or a creation date to
Person is just cruft that makes the spec more complex with no benefit.  If
it turns out that scanners can validate additional information about a
person (such as public key certificates for that email address), then
either the Person type can add a list of certificates (clumsy) or the
Certificate type can have a subject email address field (easy).

* I disagree that making everything an Element makes everything easier to
integrate with other activities.  If SPDX and Application B want to talk
about the same Person, it's far easier for them both to use email address
as the common identifier than for Application B to learn everything about
SPDX Elements and SPDXIDs.

* Identity is not a base class of Person.  Identity is a composition of
Person, Organization and Tool that does something (creates a piece of
software, creates an SPDX document, creates an annotation).  An Element can
reference an Identity and associate a creation date to the act of creating
that Element.  The Identity can reference the Person, Organization, and
Tool involved in the act of creation.

Of course decisions will be made by working through specifics of use
cases.  But I'm pretty confident that making Person (and Organization and
Tool) independent types will make every use case easier to understand and
integrate with.

v/r,
Dave


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4042): https://lists.spdx.org/g/Spdx-tech/message/4042
Mute This Topic: https://lists.spdx.org/mt/82242865/21656
Group Owner: [email protected]
Unsubscribe: https://lists.spdx.org/g/Spdx-tech/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to