ORCID iDeas Forum

Thanks for your ideas. The process to turn an idea into an active part of the ORCID Registry is described in the article How are new features decided?(see link) While we want to get to every suggestion, our limited staff time means that some features will have to wait until future development cycles. We look forward to reading your ideas.

I suggest that...

You've used all your votes and won't be able to post a new idea, but you can still search and comment on existing ideas.

There are two ways to get more votes:

When an admin closes an idea you've voted on, you'll get your votes back from that idea.

You can remove your votes from an open idea you support.

To see ideas you have already voted on, select the "My feedback" filter and select "My open ideas".

Enter your idea

(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can support and comment on it.

If it doesn't exist, you can post your idea so others can support it.

Enter your idea and we'll search to see if someone has already suggested it.

With API 2.0 all requests to /search are answered with just a list of identifiers.
This is not sufficient for many use cases and forces clients to perform additional HTTP requests in order to present search results to human users.
In my opinion the existing /search endpoint should be extended to display all available index fields if needed.
This could easily be done without breaking existing contracts, e.g. by introducing another optional request parameter that allows clients to specify what fields should come with the response or by introducing an additional content type that allows clients to ask for full records in their search requests.

With API 2.0 all requests to /search are answered with just a list of identifiers.
This is not sufficient for many use cases and forces clients to perform additional HTTP requests in order to present search results to human users.
In my opinion the existing /search endpoint should be extended to display all available index fields if needed.
This could easily be done without breaking existing contracts, e.g. by introducing another optional request parameter that allows clients to specify what fields should come with the response or by introducing an additional content type that allows clients to ask for full…

The "Structure of the ORCID Identifier" article is currently hard to find. Since the primary purpose of ORCID is issuing said identifier it would make sense to link to it from the "About ORCID" page. Possibly a whole "What we do" section for would also be nice.

While using the PaleMoon browser, I've found that orcid.org uses browser detection based on useragent and not on features, as it should be. Palemoon is an up-to-date alternative originally derived from Firefox. It does have the functionality of a modern browser. However, the ORCID site detects it as "We notice you are using an older browser"
If I change the useragent to mimic Firefox, the warning goes away, which proves detection is based on useragent.

Many co-authors and also publishers may not know how to write the author's name correctly. It would be really good, if I could put the latex code of my name to my profile. In that way, anyone can explicitly see the correct spelling of my name with accents and can also use it in the articles or the related databases.

- It would be good to allow export of citations from the public view
- It would be good that the exported bibtex would be consistent in naming the author. One basic interest of orcid is disambiguation of authors' names. The entries coming from different sources are not homogeneous in formating names (sometimes leading to erroneous spellings). At least the author from the concerned Orcid page whould be formatted correctly. At least, the first name/last name split should work!

Regarding exporting citations from the public view:
Presently one can create a print view only from a public ORCID record. Are you suggesting some other format?

Regarding the exported BibTeX:

Our BibTeX export tool exports the BibTeX already in your work’s metadata by default. If a third-party organization added a work to your ORCID record with a BibTeX citation that had different naming information, then the citation will include different information from our automatically-generated BibTeX.

The sort feature is helpful but it cannot be saved. I would like to sort based on relevance (not necessarily date or alphabetically) but cannot save it for my profile. For example, I completed a PhD but later earned a masters in another field. I would like to list my PhD first since it is most relevant. If someone looked at my record they may erroneously think I only have a masters degree. Allowing me to save my sort for my profile would be very helpful.

When a work has both Scopus and ResearchedID sources the UI shows either EID or WOSUID, depending on the primary source. But I as a user want to see all identifiers for each work. This would allow me to quickly find out which works were indexed by different citation indices.

This is something similar to what occurs when reading an ORCID record using the ORCIDAPI. When querying the /record, /activities or /works section, all identifiers for a work are displayed. You can read more about this at https://members.orcid.org/api/tutorial/reading-xml

As you note this is not the practice on the user interface at present. This is because a key principle of ORCID is that the party who adds information to an ORCID record is the party responsible for that information, and we do not add or edit that data. If all of the identifiers of a grouped work were to be displayed on the version of the preferred source of that work, then that would involve adding identifiers which a source had not asserted.

As the ORCID record owner, you can use the “Make a copy” feature to make a self-asserted version of the work and then add all other known identifiers for the work, then make that version the preferred source for that work.

Regarding future development:

This could be something that might be worth considering for addition to the ORCID Registry. It would be excellent to receive community input on good methods of display which take the above factors into account. For example, a reminder displayed to the record holder that they can create a version of a merged work which includes all identifiers? Or some other process?

We look forward to receiving your input.

Warm regards, ORCID Community Team

Thanks for your suggestion to improve the ORCID Registry.

This is something similar to what occurs when reading an ORCID record using the ORCIDAPI. When querying the /record, /activities or /works section, all identifiers for a work are displayed. You can read more about this at https://members.orcid.org/api/tutorial/reading-xml

As you note this is not the practice on the user interface at present. This is because a key principle of ORCID is that the party who adds information to an ORCID record is the party responsible for that information, and we do not add or edit that data. If all of the identifiers of a grouped work were to be displayed on the version of the preferred source of that work, then that would involve adding identifiers which a source had not asserted.

As the ORCID record owner, you can use the “Make a copy” feature to make a self-asserted…

For a work that has only a URL associated with it (particularly if it is entered manually), there are a number of places to enter it. If the URL is included as an identifier <common:external-id-type>uri</common:external-id-type>, it will be included in the /record summary view. If it is not included as an identifier, it will be included in the /work view as <work:url>. I'd like to ask that <work:url> be included in the summary view (or for work:url to be copied to identifier type uri) so as to avoid making multiple calls to pull back all possible identifiers for a given work.

For a work that has only a URL associated with it (particularly if it is entered manually), there are a number of places to enter it. If the URL is included as an identifier <common:external-id-type>uri</common:external-id-type>, it will be included in the /record summary view. If it is not included as an identifier, it will be included in the /work view as <work:url>. I'd like to ask that <work:url> be included in the summary view (or for work:url to be copied to identifier type uri) so as to avoid making multiple calls to pull back all possible identifiers for a given…

If you view an ORCID record and click on Show Details next to a publication, the upcoming detailed view looks in many cases very unattractive. You often (or always) see the record first in a bibtex view which is cryptic and hard to read. Why not showing an ordinary html view, e.g. a PubMed-like view as default?

The ORCID record is intended to be a record of your research output, affiliations, funding history, etc. We store limited metadata information for each item based on the information that you have added to your ORCID record, or that you have granted an ORCID member organization such as Europe PubMed Central to add on your behalf.

The citation that is displayed in the ORCID is based on the citation provided with the work. We recommend that BibTeX citations be added to works. This enables you to have a verbose BibTeX citation when you export your works in BibTeX format, and it includes additional information than can be stored in the ORCID record, e.g. page numbers.

Keeping the above in mind, if you have specific suggestions on how information could be displayed on the ORCID record, please let us know.

Warm regards, ORCID Community Team

Thanks for your suggestion to improve the ORCID Registry.

The ORCID record is intended to be a record of your research output, affiliations, funding history, etc. We store limited metadata information for each item based on the information that you have added to your ORCID record, or that you have granted an ORCID member organization such as Europe PubMed Central to add on your behalf.

The citation that is displayed in the ORCID is based on the citation provided with the work. We recommend that BibTeX citations be added to works. This enables you to have a verbose BibTeX citation when you export your works in BibTeX format, and it includes additional information than can be stored in the ORCID record, e.g. page numbers.

Keeping the above in mind, if you have specific suggestions on how information could be displayed on the ORCID record, please let us know.

We will flag this for our team to look into for future development of our BibTeX parser.

You can help this process by joining our efforts. ORCID is an open-source project that relies strongly on community support. We welcome your contributions to improve our BibTeX parser: https://github.com/ORCID/bibtexParseJs

We have as flagged as a future improvement possibility adding more verbose error messages in response to BibTeX import issues. As we consider this feature, it would be helpful if you could suggest what information you would expect to see during the error report.

In addition, please note that generally we encourage you to import works using the machine-to-machine connections using our Search & Link wizards, such as Scopus, ResearcherID, EuropePubMed Central, and Crossref.

If you are experiencing problems with importing a specific BibTeX file, please get in touch with support@orcid.org and provide both the file as well as the system from which it was generated. There are some systems, such as EndNote, which require that you apply additional filters when generating the original BibTeX file, as those systems may include nonstandard or unsupported information in the BibTeX.

Thank you.

Warm regards, ORCID Community Team

Thanks for your suggestion to improve the ORCID Registry.

We have as flagged as a future improvement possibility adding more verbose error messages in response to BibTeX import issues. As we consider this feature, it would be helpful if you could suggest what information you would expect to see during the error report.

In addition, please note that generally we encourage you to import works using the machine-to-machine connections using our Search & Link wizards, such as Scopus, ResearcherID, EuropePubMed Central, and Crossref.

If you are experiencing problems with importing a specific BibTeX file, please get in touch with support@orcid.org and provide both the file as well as the system from which it was generated. There are some systems, such as EndNote, which require that you apply additional filters when generating the original BibTeX file, as those systems may include nonstandard or unsupported information in the BibTeX.

We will be using your feedback to improve affiliations as a part of our development for API 3.0. Keep watch on our Current Development Trello board / GitHub for our work on 3.0: https://trello.com/b/iuJwm8A6

It would be a good idea to divide authors' names in three parts instead of two: for instance, Dutch authors often have insertions in their names: given name, insertion(s), last name. Insertions can be for instance "van", "de" or "van de", causing authors, as it is now, to be found under the V or D of the insertions instead of under the first letter of their last name. A solution could be a third or middle box, in which insertions can be filled in. That could also be used by people who want to use their middle name: alphabetizing for instance "John G. Field" and "Jan G. van den Akker" would give "Field, John G." and "Akker, Jan G. van den"; the correct forms. I understand that in ORCID filling in a last or family name is not required; in the same way such a third box for insertions could be set to not required.
I also posted this idea on Mendeley, hopefully that is no problem.

It would be a good idea to divide authors' names in three parts instead of two: for instance, Dutch authors often have insertions in their names: given name, insertion(s), last name. Insertions can be for instance "van", "de" or "van de", causing authors, as it is now, to be found under the V or D of the insertions instead of under the first letter of their last name. A solution could be a third or middle box, in which insertions can be filled in. That could also be used by people who want to use their middle name: alphabetizing for…

There have been several ideas related to the current work categories and types on the ORCID record and suggestions for addition and improvement. This thread will combine these ideas together, as well as serving as a place to discuss additional suggested categories or work types.

By way of background: The current listing of work types (see https://members.orcid.org/api/supported-work-types) is sourced from the CASRAI Output Standards. We would now like to open a discussion about the best approach to adding future work categories and types with the ORCID Community, through our iDeasForum.

Thank you for your suggestions to improve the ORCID Registry.

There have been several ideas related to the current work categories and types on the ORCID record and suggestions for addition and improvement. This thread will combine these ideas together, as well as serving as a place to discuss additional suggested categories or work types.

By way of background: The current listing of work types (see https://members.orcid.org/api/supported-work-types) is sourced from the CASRAI Output Standards. We would now like to open a discussion about the best approach to adding future work categories and types with the ORCID Community, through our iDeasForum.