-
Notifications
You must be signed in to change notification settings - Fork 1
/
README
102 lines (76 loc) · 3.58 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
A collection of mod_python based REST services. Many of these services
are actually simple front ends to other SOAP based web services. While
the code can be downloaded and run from any machine (with mod_python
and Apache) they will be dependent on remote SOAP services.
* format
------
Requires that OpenBabel and its Python bindings be installed
* substruct
---------
Requires that OpenBabel and its Python bindings be installed
Supports GET or POST requests. If the former then the URL should be of the form
/substruct/TARGET/QUERY
where TARGET is a SMILES string for the target molecule and QUERY is a SMARTS
(or SMILES) pattern. Both arguments should be appropriately escaped. The return
value is either the string "true" or "false" if the query matches the pattern
respectively.
If a POST request is recieved then the service expects two form variables:
- query - a single string containing the SMARTS pattern
- target - a comma separated string of one or more SMILES strings
The return value will be a multiline plain text document. The number of
lines equals the number of input SMILES. Each line is either "true", "false"
or "fail". Thus if the i'th row is "true", the i'th target molecule contained the
query. The string "fail" implies that there was an error parsing the SMILES
string.
* predict
-------
Requrements: Python 2.4 or better
R 2.7.2 or better
rpy2
Dependency : descriptor service
Services that will use R via rpy2 to obtain predictions from
previously built statisticalk models. These services are oriented
to QSAR models, so the input to these services is usually a Base64
encoded SMILES string.
The entry point to this service is dispatch.py which investigates the
URL to identify which model is to be used to obtain predictions. To
obtain a list of models visit the URL (return type is text/plain)
/predict
To get the details of a model (return type is text/xml), visit
/predict/ModelName
To obtain a prediction from a model, visit
/predict/ModelName/SMILES
where SMILES should be the Base64 encoded SMILES string. If an invalid
model name is specified, a HTTP 404 error is returned.
Each model should be stored in a Rda file (use "save" in
R). Currently, only models that have an associated "predict" method
are considered. Furthermore, the file should have a single model
object called "model". This is currently a bit restrictive and future
versions will probably encode the name of the model object in the
manifest.
The service can handle multiple models via a model manifest. This is
an XML document, listing the details of one or more models and is
shown schematically below:
<modelManifest>
<model title="A model title" name="ModelName" rda="theModel.Rda">
<author>The Modeler</author>
<date>01-13-2009</date>
<description>A description of the model</description>
<descriptors>
<descriptor class="xxx" value="xxx" />
<descriptor class="xxx" value="xxx" />
<descriptor class="xxx" value="xxx" />
</descriptors>
<model>
<model ... >
...
</model>
</modelManifest>
Essentially the manifest describes the descriptors required for the
model, along with other details such as the Rda file containing the
model. Right now only CDK descriptors are supported and are accessed
via the descriptor REST service. The _class_ attribute should be the fully
qualified class name of the descriptor and _value_ should be the name
of the specific descriptor value employed in the model. See
http://cheminfo.informatics.indiana.edu/~rguha/code/java/nightly-1.2.x/dnames.html#molecule
for a list of descriptors and their individual values.