| |
The ProteomeXchange ProteomeCentral server has two main components, the front-facing dataset browsing interface and the back-end dataset management/announcement system. The front-facing dataset browsing interface is largely self-explanatory and is accessible to a web browser at http://proteomecentral.proteomexchange.org/. The back-end dataset management/announcement system is used as a web service by automated software rather than interactively via a web browser. This page provides documentation to this web service.
The primary workflow for registering datasets via ProteomeXchange is as follows:
| Primary | Primary service that should be used by all repositories: http://proteomecentral.proteomexchange.org/cgi/Dataset |
| Beta | For testing new unreleased code in the service as appropriate: http://proteomecentral.proteomexchange.org/beta/cgi/Dataset |
| Backup | If the production code is failing due to recently-added features, the backup area contains a previous checkpoint of known-stable code. All handling repositories should implement a strategy to fail over to this backup area if they are unable to use the production code area and unable to wait for a fix. http://proteomecentral.proteomexchange.org/backup/cgi/Dataset |
Parameters for the Dataset service are described below. It is recommended that parameters be passed to the service via the HTTP POST protocol. See at the bottom for a sample Perl and Java code implementation of communication with the service:
All these parameters are case sensitive
| PXPartner | Username of the ProteomeXchange partner that is acting as the hosting repository for a dataset. This name is assigned by ProteomeXchange. A value of “TestRepo” may be used for testing. |
| authentication | The authentication string/password for the specified PXPartner. Authentication strings are provided upon request to prospective ProteomeXchange partners. |
| method | The desired method call for the invocation of the service. This service offers several different methods, which are described in the next table below |
| test | If set to “true” or “yes”, then all actions occur in the parallel test area/database, which does not share entries with the production database. The general use of the test flag is to request an ID with test set to true, and then submit a dataset using that furnished accession with test still set to true. A production accession number cannot be submitted in test mode, since it does not exist in the test database. |
| verbose | This parameter is intended to control the verbosity level of the response. At the present time, this really has no effect and all responses are fairly verbose in the INFO fields. See documentation for the service responses below. |
| ProteomeXchangeXML | This field specifies MIME-encoded XML document that is to be submitted to the service. It is encoded as if being supplied to an HTML file widget. See sample code on how to do this programmatically. |
| noEmailBroadcast | If set to “true” or “yes”, the normal email/RSS broadcast that accompanies email submission is suppressed. This may be useful for extensive testing where repeated emails may become tiresome to developments, or in cases where many production submissions need to be updated trivially to support new ProteomeXchange features (such as “lab head”) without a desired email for each one. |
| noDatabaseUpdate | If set to “true” or “yes”, then all code will be executed until the last moment when a database record would be written or updated. Instead the service ends there with a note that everything was successful or unsuccessful. This also serves as another type of test mode that can act on the production database without actually making any changes to it. |
| reprocessed | This parameter is only used when requesting new identifiers to signify that the identifier is for a reprocessed dataset. Most repositories are not registered to submit reprocessed datasets. |
| serverStatus | A simple call that returns SUCCESS if the ProteomeCentral service is alive and operating normally as far as it is aware. |
| testAuthorization | Requires parameters PXPartner and authentication, and returns SUCCESS if the supplied credentials are valid such that more complex options could take place. |
| requestID | Requires parameters PXPartner and authentication, and returns SUCCESS and a ProteomeXchange accession number if credentials are valid. If the test parameter is set to true or the authorized user is jailed in test mode, then the supplied access will be an accession from the test database instead of the production database. If the reprocessed parameter is true, then an RPXD accession is furnished for reprocessed datasets. |
| submitDataset | This method requires that a MIME-encoded XML document be provided via the ProteomeXchangeXML parameter in addition to the proper credentials. If the XML is valid and all checks are passed, the dataset is written to the database, is available on the web site, and an email/RSS announcement is sent. |
| validateXML | This is similar to submitXML, except that the uploaded XML is validated for correctness, both at the structural schema level as well as the semantic level. If there are any problems with the XML, they are listed in the INFO fields. Severe schema problems will cause an error, but minor semantic issues merely generate warning messages and the validation may return SUCCESS. A return value of SUCCESS does not therefore mean that the file is fully valid, merely that the validation completed successfully and problems were successfully reported. |
There is a test form that can be used to interact with the service.
But most likely you will want to interact with the service programmatically. Here are a few examples:
If you have a question or comment about ProteomeXchange, please contact us! to receive all new ProteomeXchange dataset release announcements!
|
|