New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Person identifiers in respositories exported in metadata to third parties #14

Open
MonicaDukeJisc opened this Issue Sep 4, 2018 · 3 comments

Comments

Projects
None yet
2 participants
@MonicaDukeJisc
Copy link

MonicaDukeJisc commented Sep 4, 2018

As an institutional repository manager, I want to expose metadata about the resources in my repository to downstream services, in a way which optimises the processing of the metadata by those services.

With respect to person identifiers in Dublin Core I want to be able to:
a. Indicate which scheme this identifier is generated from (this can indicate how this identifier can be resolved)
b. Be able to share more than one identifier from different schemes, showing these identify the same person.
c. Include provenance information with the identifier
c.2) With respect to ORCID specifically, whether this ID is authenticated

This use case is derived from discussions in the UK ORCID consortium recorded at:
https://docs.google.com/document/d/1SxN6UGppByvo1f-N_YJMm7k4Y-fVHAF0SGtmpL9jYNM/edit#
The input of the UK community is acknowledged

Comments on implementation options and examples:
Using an id= attribute, as referred to in the Unesco document http://unesdoc.unesco.org/images/0023/002321/232199E.pdf (page 58) with the approach:
syntax: <dc:creator id=http://”identifier-for‐this-creatorentity”>name‐of-this-creator-entity</dc:creator>
Example <dc:creator id=http://orcid.org/0000-0002-1395-3092>Mishra, Sanjay</dc:creator>

Limitations: The identification scheme is not known with this format.
A limitation could be expressed to allow values from one identifier scheme only - which would then not meet requirement (b) to allow multiple id schemes to be expressed

Regarding (a) and (b) the ideal is to allow:
<dc:creator orcid="xxx" isni="yyy">

For requirement (c) provenance information could include whether the ID was verified locally (ie with the involvement of the user doing an authenticating process), whether it was harvested from an external system.
Questions: how much and what provenance information is needed?
E.g. if indicating an authenticated ID, do you also need to keep the provenance of that claim?

The requirement for provenance information is so that downstream systems can then make processing decisions based on whether they consider the provenance entity to be trustworthy (e.g. they could discard the ORCID ID or incorporate them into their own records).
Example of provenance from crossref
https://support.crossref.org/hc/en-us/articles/214567746#ORCID uses an authenticated=true attribute

Example for including ORCID ID in RDF export as implemented in eprints Advance ORCID plugin, 2018

http://eprints.soton.ac.uk/id/person/ext-98efd447-4aa7-411c-86d1-955a612eceac
foaf:familyName "Gibbins"^^xsd:string;
foaf:givenName "Nicholas"^^xsd:string;
foaf:name "Nicholas Gibbins"^^xsd:string;
owl:sameAs http://orcid.org/0000-0002-6140-9956
rdf:type foaf:Person

@paulwalk

This comment has been minimized.

Copy link
Collaborator

paulwalk commented Sep 4, 2018

Thanks - this is nice and clear. The requirement for provenance assertions adds significant complexity to the requirements and may be beyond a DCMI recommendation which can be widely adopted - but this should certainly go into the discussion.

@MonicaDukeJisc

This comment has been minimized.

Copy link

MonicaDukeJisc commented Sep 5, 2018

I think it would be really great if the workshop could unpack the requirement a little further. Also think about, is there anything about PIDs that makes it more critical to know their provenance than other metadata? Repository managers and harvesting systems are needing to decide now 'do I store and trust this PID that I've received, and do I share it on?' However if that's what they've been doing with other metadata, what is different about PIDs?

@paulwalk

This comment has been minimized.

Copy link
Collaborator

paulwalk commented Sep 5, 2018

Yes - agreed - this is a good topic for discussion at the meeting. I am finishing a little 'position paper' today which, I hope, will seed the discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment