# Background We have received a number of questions about how DOI aliases are treated. Q1: When performing aggregation, which way do you count, counting only Primary or counting both Primary and Alias DOIs? Q2: What data do you maintain for Alias DOIs? As you answered to Jonathan "The DOI doesn't have any metadata - it just redirects to the active DOI.", I would like to learn more on this point. When you alias a DOI with a Primary DOI, do you remove such metadata as title and authors from the alias DOI? Also, in addition to the pointer between a Primary DOI and its Alias DOIs, what information do you maintain between them? For example, the date of getting aliased? Q3: This Q is related to the above Q2. We are wondering what metadata of Alias DOIs can be retrieved? Also, is there any metadata channels which suppress metadata to be retrieved? We are asking these questions since some metadata for an Alias DOI, 10.6011/apj.2020.01, seems to be retrieved as https://api.crossref.org/works/10.6011/apj.2020.01 Also, metadata seems to be retrieved using another API which is available to the members. Q4: Is there any tool which let us know the relationship between Primary DOIs and their Alias DOIs? For example, when specifying an Alias DOI, then returning with its Primary DOI. Or, in a reverse way, when specifying a Primary DOI, then returning with its Alias DOIs. Can we learn if there is such a tool or not? Q5: When we retrieve metadata with a query of authors, issue, volume, pagination, which DOIs will be shown, only the Primary DOI or both the Primary DOI and its Alias DOIs? Q6: When an article with a Primary DOI and Alias DOIs is cited by another article, which do you count "+1" as Cited, for only the Primary DOI or for both the Primary DOI and the Alias DOIs? # 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.) [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: @bvickery1 - [ ] Tech lead: - [ ] Service:: label applied - [x] 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 - [ ] Knowledge base reviewed and updated - [ ] Public documentation reviewed and updated - [ ] Acceptance criteria met - [ ] Q1 - [ ] Q2 - [ ] Q3 - [ ] Q4 - [ ] Q5 - [ ] Q6 - [ ] Response drafted - [ ] Acceptance testing passed # Notes [comment]: # (By default all issues need to be labeled Planning::New, only remove if you know what you're doing)