Closed apirogov closed 11 months ago
@apirogov: The current compose in codemetapy is a simple overwrite on the triple level and triples for which are not in the new graph are removed than there is an rdf merge. There is no entity resolution implemented in codemetapy, but this is also stated in the readme.
I can image that one can do better.
A simple rdf merge could already be better (in some cases), but would not be enough, since it only works for objects with identifiers in both graphs. But it would at least merge the email if the second person also has an orcid as identifier, due to a usual rdf merge, please check if this is the case. I am not sure how blank nodes are handled in detail in codemetapy.
The current compose in codemetapy is a simple overwrite on the triple level and triples for which are not in the new graph are removed than there is an rdf merge. There is no entity resolution implemented in codemetapy, but this is also stated in the readme.
Correct, it overwrites the entire triple. This behaviour is by design so you
can compose a codemeta file from multiple input files, where the ordering
determines which takes priority. This behaviour is used by
codemeta-harvester
.
A simple rdf merge could already be better (in some cases), but would not be enough, since it only works for objects with identifiers in both graphs.
Yes. If you want a merge, the only way to do so currently is to ensure the authors
have the same @id
. So if everything already has ORCIDs it'll work fine.
I realize it's sub-optimal and some better mechanism could be implemented
However, merging multiple instances of persons is more tricky than it might
seem. Names are not always consistent (an extra middle name, a missing
diacritic, etc). Then which do you choose? We definitely don't want to end up
with multiple givenName
and familyName
properties. Multiple emails or urls
may be ok.
Another challenge is when having a graph of multiple SoftwareSourceCode instances (which codemetapy supports) where an author appears in multiple projects; but what if he/she has different affiliations in such a context?
Closing as 'invalid' since it's not a bug but by design. But of course the question and discussion itself (feel free to continue here) is very valid, and a better solution may be devised.
File
in1.json
:File
in2.json
:Run
codemetapy in1.json in2.json
Expected result:
Person will have both email and orcid
Actual result:
Person has only email (when passed in this order) or only orcid (when passing
in2.json
beforein1.json
)