Describe people using SOSO guidelines

[ThomasThelen]

Transform the representation of people affiliated with datasets to conform to schema,org. This is most likely a large task that involves a few parts...

• Refactoring the internal representation of people. Right now they’re represented under the geolink vocabulary. When making the switch to schema,org we should replace the terms with schema,org ones (isomorphic with foaf)
• Connecting datasets to them. SOSO connects people to datasets through roles, which we should be able to determine from the science metadata document.

[ThomasThelen]

Some misc thoughts.

One concern that I have is answering "What is the authority for defining a person?".

For example, what happens when I submit a dataset that lists my first and last name along with my email address-and then submit a second dataset where my email has a typo in it? Depending on how we harvest information, we're going to

1. Have a node with two email addresses. This is arguably useful when asking "What are the email addresses for the node with some property X?" (you'd get the correct and incorrect one). Or "What is the subject with email address mailto:thelen@nceas.ucsb.edu?".
2. Have two nodes, each with different email addresses (this is iffy because it implies the the email is the "unique key". If that's the case, then I've accidentally defined a new person, and the graph has to respect that)
3. A single node, with the email address overwritten with the incorrect one

Are there any fields that are absolutely required across all the metadata standards that we can use as a key to define a person? Some documents have ORCIDS, some don't; I don't think we can't use ORCID as the identifier because there's not consistent behaviour across metadata entries.

One option (on the extreme side) that I see is saying less, but being more accurate in our description by not parsing fields that we allow users to fill out (ie the contacts, creators, etc in the EML). Instead, taking whatever piece of identifying information DataONE has about each user (there has to be a way that DataONE distinguishes users from each other) and mapping it into the graph. This would let us say, with complete confidence who created a dataset without the possibility for user error

[mbjones]

@amoeba and I went through a long process to establish an algorithm of disambiguating identities for people during GeoLink. I believe the current code includes an implementation of the logic we arrived at. The crux is that we wanted to 1) combine nodes together under a single Person node whenever we could unambiguously (100%) determine that the records refer to the same real world person -- this generally required multiple matching metadata fields in various combinations, and 2) when we couldn't be 100% sure of the match, then separate Person nodes are created, but the nodes are linked together to indicate our degree of confidence. I have forgotten the details of this linking, but maybe @amoeba can refresh us. The overall matching pattern is described here: https://github.com/DataONEorg/slinky/blob/main/d1lod/docs/proposal.md#people But I forget how the machine learning matches are represented in the graph.

[mbjones]

In rereading the document above, I see it also talks a bit further down about the matching predicates, but doesn't specify exactly what they are. Conceptually, they are matches, hasAccount, and hasConfirmedMatch, but I don't what vocabulary we used for those. @amoeba can you clarify?

[amoeba]

I don't think that section ever got implemented. Collaborators at Wright State were working on the co-reference resolution side of things but it never got formal enough to go in. In my attempts, I never found anything that worked better than hard-coded logic but I think hard-coded logic actually works really well. What's implemented now can be pushed a lot further, beyond name+email matching.