Should ORCIDs be used in the RDF interface where available?

[jesusbagpuss]

By default, EPrints generates a URI based on the person->id, or the person->name (with some extras thrown in): https://github.com/eprints/eprints/blob/v3.3.16/lib/cfg.d/rdf_uri_person.pl

Should this config be changed (redefined in the archive cfg.d) to use $person->{orcid} by default?

The code could be put into e.g. z_orcid_rdf_person.pl.example so it has to be explicitly enabled?

[jesusbagpuss]

NB changing the above would require regenerating the RDF triples.
It would also mean once a triple has been updated, the old URI wouldn't resolve.

An alternative approach (which might actually be more sense) would be to add a new EP_RDF_TRIGGER that replicates this https://github.com/eprints/eprints/blob/v3.3.16/lib/cfg.d/rdf_triples_bibo.pl#L384-L527, but calls a new config method e.g. $c->{rdf}->{person_orcid_uri} instead.

[wfyson]

Just doing a bit of long overdue tidying up of issues and pull requests in the ORCID plugins... does https://github.com/eprints/orcid_support_advance/blob/master/cfg/cfg.d/z_orcid_support_advance_rdf_triples.pl fix this issue @jesusbagpuss? It's in the Advance plugin rather than the basic one, but can we close this?

[jesusbagpuss]

@wfyson - just doing an even more overdue tidying of things...
There is an issue with the current rdf-triples solution. I have logged this and proposed a solution/submitted a PR: eprints/orcid_support_advance#80

It feels like the solution in the advance plugin might better live in here - if an EPrints repo is connected to a CRIS system, the advance plugin might not be installed/active, but the RDF would still benefit from having ORCIDs in it?