# Background [comment]: # (If this is a bug, fill in the following sections) When a relationship is asserted in the metadata deposit for a given item, the reciprocal relationship should be added to the related item's metadata record. For the isReviewOf relationship, at least, this seems to be working in the XML API, but not in the REST API # Observed behavior [comment]: # (Please provide as many details as you can about steps to reproduce, operating system, browser, and version used, screenshots, example submission IDs, example XML, example queries, etc) As an example, 10.3410/f.1097479.553550 is a peer review of 10.1093/dnares/dsm018 In the XML API, you can see that the isReviewOf relationship has been supplied by the publisher of 10.3410/f.1097479.553550 http://doi.crossref.org/search/doi?pid=support@crossref.org&format=unixsd&doi=10.3410%2Ff.1097479.553550 ``` <ns5:program xmlns:ns5="http://www.crossref.org/relations.xsd"> <ns5:related_item> <ns5:description>Faculty Opinions recommendation of Comparative metagenomics revealed commonly enriched gene sets in human gut microbiomes.</ns5:description> <ns5:inter_work_relation relationship-type="isReviewOf" identifier-type="doi">10.1093/dnares/dsm018</ns5:inter_work_relation> </ns5:related_item> </ns5:program> ``` And correspondingly, a reciprocal relationship has been included in a crm-item for 10.1093/dnares/dsm018 http://doi.crossref.org/search/doi?pid=support@crossref.org&format=unixsd&doi=10.1093%2Fdnares%2Fdsm018 `<crm-item name="relation" type="doi" claim="isReviewOf">10.3410/f.1097479.553550</crm-item>` [I believe that should say "hasReview" rather than "isReviewOf" though? But, that seems like a smaller problem.] In the REST API for 10.3410/f.1097479.553550 you can see the same relationship metadata in the JSON http://api.crossref.org/works/10.3410/f.1097479.553550 ``` "relation": { "is-review-of": [ { "id-type": "doi", "id": "10.1093/dnares/dsm018", "asserted-by": "subject" } ] ``` But the REST API record for 10.1093/dnares/dsm018 has no indication of the relationship http://api.crossref.org/works/10.1093/dnares/dsm018 # Expected behavior [comment]: # (What did you expect to happen before you observed the anomalous behavior?) Both sides of any relationship should be apparent in the REST API. # How urgent [comment]: # (There are myriad factors that go into prioritizing and scheduling development work, but any information you can provide to help us understand severity, urgency, relative priority, or deadlines, is much appreciated.) This impacts potentially all REST API users, including Plus users. It was reported by someone who saw the relationship Crossmark and didn't understand where it was coming from. So, that's pretty broad ranging. [comment]: # (No need to update the Definition of ready when filing issues, but feel free to have a go if you're familiar with the territory.) # Definition of ready - [x] Product owner: @ppolischuk1 - [x] Tech lead: @dtkaczyk - [x] Service:: label applied - [ ] Definition of done updated - [ ] Acceptance testing plan: - [ ] Weight applied [comment]: # (Feel free to leave this as is, or suggest changes. We'll update these during Backlog Refinement, prior to bringing this into a sprint.) # Definition of done - [ ] Unit tests identified, implemented, and passing - [ ] Code reviewed - [ ] Available for acceptance testing via a staging URL, or otherwise - [ ] Consider any impacts to current or future architecture/infrastructure, and update specifications and documentation as needed - [ ] Knowledge base reviewed and updated - [ ] Public documentation reviewed and updated - [ ] Acceptance criteria met - [ ] AC 1 - [ ] AC 2 - [ ] Acceptance testing passed # Notes [comment]: # (By default all issues need to be labeled Planning::New, only remove if you know what you're doing)