The Neurolex Wiki is a curated site; that is, members of the NIF and affiliated projects regularly review the content and may modify it as necessary. The Wiki was set up for the purpose of providing the community an opportunity to contribute categories and definitions to enhance description and access to neuroscience-relevant data. The concepts contributed on the Wiki are used to help build the NIF ontologies.
When new categories are created or new relationships added, the NIF curators determine whether the category needs to be added to our ontologies. This determination is made based on whether we have a current ontology covering the domain, whether the category is unique, that is, it does not already exist under another label, and whether it is relevant to the mission of the NIF. If these conditions are met, the category is added to the NIFSTD ontology.
Categories that are added to the NIFSTD receive a unique identifier, usually of the form nlx_####. If the category already exists in a community ontology, the identifier assigned in the original ontology is reused. If a category is determined to already exist, the label used is usually added as a synonym to the existing category. In this case, the original category page is usually deleted. Any changes to a page can be viewed by clicking on the "history" tab.
How to curate a resource in the Neurolex
The Neurolex provides a comprehensive listing of resources that are relevant to neuroscience research. Resources include databases, software tools, materials, services and other useful websites. To add a resource, we have created a special form that can be accessed by entering the name of the resource in the "Create a new resource" box on the home page. Here are some guidelines for how to describe and classify resources:
1) Avoid special characters like "/", ":"as no one will query for them.
2) Avoid sloppy looking names with extraneous information, e.g., Neuroanatomy Lab Resource Appendices: Sectional Atlas. "Lab Resource Appendices" isn't the name of the resource. If there isn't an official, acceptable name, then create one: Sectional atlas of human brain.
3) Avoid extra description in the title. Remember, these will be used for search and for alphabetizing. The name of the resource should be the common name:
Yes: Flybrain; No: FlyBrain, An Online Atlas and Database of the Drosophila Nervous System.
4) Do not put a version number in the title of the resource, as these change over time:
Yes: MathML No: MathML 2.0
5) Abbreviation vs full name. We have not been consistent here, but it appears that the best strategy is to prepend the abbreviation, e.g., CODR: C-Path Online Data Repository. The abbreviation should be entered into the abbreviation field; the full name into the "other name" field.
1) what is the main thing offered by this resource? Data, tools, analysis? While it is tempting to copy the description of the resource, please do not do this indiscriminately. These descriptions will be displayed as snippets by many tools that access the resource registry. Thus, the first line of the description should be as informative as possible. Do not repeat the name of the resource.
Let's say we wanted to add a resource that is called: Cow brain gene expression atlas
Good leading sentence: Atlas detailing the three dimensional expression of 20,000 genes across major regions of the cow brain...
Bad leading sentence: The Cow Brain Gene Expression Atlas was developed by the University of X and aims to provide an increased understanding of ..."
2) Please remove any brackets that might be used for references or any type of parenthetical phrase. Brackets are interpreted by the wiki and will lead to errors in formatting.
3) Make sure to eliminate and breaks that might have been inserted in the html, as that makes the description look sloppy.
4) Avoid using terms that have a time component, e.g., "new", "recently", because these can become out of date and misleading pretty quickly.
5) Avoid using the personal pronoun when describing the resource, as NIF's descriptions should not be from the resource providers point of view, e.g., do not say "We offer...".
6) Remove any qualifiers used in the resource description that are subjective and not-informative, e.g., cutting-edge, most comprehensive available, global leader. Pay particular attention to this policy if you are curating a commercial site. Their descriptions have been written by public relations experts, not scientists.
Assigning resource type or types can be challenging, as many websites offer multiple products and an individual product can serve multiple roles. In general, if you have to assign too many labels, you are probably better off creating separate pages for some of the tools, rather than trying to characterize everything a particular resource has to offer in total.
The resource type assigned should be the answer to this question:
What is the primary product offered at this web address?
Software tool? A data set? A service?
That is, what would a user expect to take away from this site? Avoid assigning resource types for very minor functions. For example, if a site offering a database on nucelolar proteins has a discussion tab where they advertise a position for hire, do not characterize this resource as a job resource. A user should always understand why he or she was taken to a site, i.e., they shouldn't have to dig for information-it should be obvious. You may use the keywords to add additional resource descriptors if you think they are highly relevant.
Software tools: Software tools are categorized by function, e.g., simulation software is software that is used to perform simulation. Do not use a specific function term unless the software is designed for that function. If the site has a database of models that may be derived from or used for simulation, it is not simulation software. In this case, use the term "simulation" as a keyword.
Consult the NIF resource type ontology for resource types. The NIF project also has additional guidelines on curating resources. All resources are curated by the NIF curator, so do not be concerned if you have difficulty.
Keywords should be used to supply related terms that characterize the resource that may or may not be in the ontology. Keywords should be "meaty", that is, they should convey specific information content and be likely search terms, e.g., proteomics, is a good keyword, as people are likely to search for that and we do not list it as a resource type. Avoid generic keywords like "experiment", "species", "science", "discipline". Use the keywords for ancillary functions of a resource, e.g., ModelDB imports and exports models for simulation. It isn't a "simulation resource", as it is not used as a platform for simulation. It is, however, related to simulation and that would be an acceptable keyword.
Other curation best practices
1) Remember that the goal of these descriptions is to be used for search across resources. Information, as far as possible, must be machine readable and human readable. Therefore, do not just copy terms, but curate them so that they are machine readable and human readable. Two examples will illustrate:
--"Contract #s N01-HD02-3343, N01-MH9-0002, N01-NS-9- 2314, -2315, -2316, -2317, -2319, -2320" was entered into the "supported by" field. Note, that if I were looking for N01-NS-9-2316, I would get zero results. A human knows what that list means but to get the computer to know requires additional programming. Curate by supplying the complete grant number.
--Keywords: Longitudinal fasciculus (LF), medulla oblongata (MO), etc. I came across this example the other day where someone had copied a list of anatomical regions into the keywords from the website, including the abbreviations. All were red links, because the Neurolex did not recognize the string "Longitudinal fasciculus (LF)", whereas when I removed the abbreviation, it became a blue link. Also, abbreviations like LF cause more harm than good, as they are very general and non-specific.