This service is designed to request that new phenotypes be added to the HPO and give a handle to requested phenotypes whilst they're being considered for inclusion.
{
'id': 'TEMPHPO_...', /* The id of this phenotype within the request service */
'name': '...',
'status': '...', /* See the status below */
'synonyms': ['...', '...', ],
'description': '...',
'issueNumber': '...', /* The github issue number in the HPO's github */
'parents': ['...', ], /* The ids of this phenotype's parents */
'hpoId': '...', /* The id of the term in the HPO. Non-null iff status == ACCEPTED */
}
One of:
SUBMITTED
REJECTED
ACCEPTED
PUBLISHED
Create a new phenotype request. If one already exists with that same name or as a synonym of this one, none will be created, and the previously existing one will be returned.
A Phenotype object, missing the id
, status
, issueNumber
and hpoId
fields.
{
'name': '...',
'synonyms': ['...', '...', ],
'description': '...',
'parents': ['...', '...', ],
}
If the phenotype has already been requested, the response code will be HTTP 409
.
Otherwise it will be HTTP 201
.
In either case the new (or previously existing) phenotype will be returned (see above for phenotype object format).
Where id
is either a TEMPHPO_
style id or an HP_
type id.
If the phenotype exists and is not in PUBLISHED
status, it will be returned.
If the phenotype exists but is in PUBLISHED
status, a truncated version of it will be returned,
containing only the hpoId
of the phenotype.
If the phenotype does not exist, an HTTP 404
will be returned.
If the id is malformed, an HTTP 400
will be returned.
Note that the returned Phenotype may have a different id
or hpoId
than that requested,
since it might have been accepted as a synonym of a different phenotype.
Search the phenotypes that match a given text.
{
'text': '...',
}
[{...}, ...] /* the results as phenotype instances */
In order to run the webapp, you need to edit its web.xml. In particular, these parameters must be set on the TermRequester servlet:
<init-param>
<param-name>org.phenotips.termrequester.repositoryOwner</param-name>
<param-value></param-value>
</init-param>
<init-param>
<param-name>org.phenotips.termrequester.repositoryName</param-name>
<param-value></param-value>
</init-param>
<init-param>
<param-name>org.phenotips.termrequester.oauthToken</param-name>
<param-value></param-value>
</init-param>
<init-param>
<param-name>org.phenotips.termrequester.homeDir</param-name>
<param-value></param-value>
</init-param>
To develop for the termrequester, you should:
- build and install the phenotips variant store
- populate
backend/src/test/resources/org/phenotips/termrequester/github/credentials.properties
by copyingcredentials.template.properties
in that same directory
To simplify automatic interaction with github, the tool adheres to a few standards:
- The issue body of tool-opened issues will match the following format:
SYNONYMS: ...
PARENTS: ...
nDESCRIPTION: ...
HPO_ID: ...
This issue was autogenerated by phenotips.org
With HPO_ID
initially being populated as NONE
.
- Accepted phenotypes should be given the label
acceptedautorequest
- Phenotypes accepted as synonyms of others should be given the label
synonymautorequest
- The issue body for accepted phenotypes should be modified to match the eventual format of the
accepted phenotype. Thus, for example, the
DESCRIPTION:
line should be changed to reflect the description of the newly added term in the HPO. Importantly, theHPO_ID:
line should be populated by the id of the new term. - Rejected phenotypes should be given the label
rejectedautorequest
- Once a version of the HPO is released that contains a given
acceptedautorequest
labeled phenotype, said phenotype should have its label changed topublishedautorequest