Dear Pantelis, All,


chung wrote:
> Dear All,
>  Using the same pattern with the existing services, I think we can have
> a service that calculates the domain of applicability (DoA) of a certain
> model. Starting with a brief definition, a DoA service tells whether a
> compound can be used by a model. So, at first, a POST operation at :
>
> /algorithm/{doa_id}
>
> of a model_uri, will return another model uri. Clients can now post
> datasets on that model uri to get another dataset which has an extra
> feature (call it for instance http://sth.com/feature/doa ) which is
> boolean and 1 corresponds to "compound belongs to the doa of the
> underlying models" and  to the opposite.
>   
Seems fine, besides that output of AD model might be probability -based,
rather than yes/no.   This could be handled via multiple feature_uris,
returned by the model.
> This proposal assumes no modification of the current API and if there is
> no objection on that we could implement a doa service based on the
> method of "leverages".
>   
If accepted, algorithm types ontology will need to be extended with a
subclass for applicability domain.

Best regards,
Nina


> Best regards,
> Pantelis
>
>
>
> On Mon, 2010-01-18 at 11:46 +0200, Nina Jeliazkova wrote:
>   
>> Hello All,
>>
>> Some discussion points for today meeting:
>>
>> 1. Data processing Algorithms.  All algorithms are subclasses of 
>> http://www.opentox.org/api/1.1#Algorithm
>>
>> Generic input parameters:
>> dataset_uri (as with other algorithms)
>> parameters
>>
>> a) Data cleanup algorithms. Algorithm, which is a subclass of   
>> http://www.opentox.org/algorithms.owl#DataCleanup
>> input parameters: generic
>> output parameters: dataset_uri
>>
>> b) Feature selection algorithms  , subclass of 
>> http://www.opentox.org/algorithmTypes.owl#FeatureSelection
>> input parameters: generic
>> output parameters:  feature_uris[]
>>
>> c)Supervised learning algorithms , subclass of 
>> http://www.opentox.org/algorithmTypes.owl#Supervised
>> input parameter:   prediction_feature
>> output parameters:  dataset_uri
>>
>> d)Descriptor calculation algorithms   subclass of
>> http://www.opentox.org/algorithms.owl#DescriptorCalculation
>>
>> input parameters: generic
>> output parameters:  dataset_uri
>>
>> http://opentox.org/dev/apis/api-1.1/Algorithm  entry is (partially) updated
>>
>>
>> 3) How to identify features, generated by an algorithm and specific set 
>> of parameters:
>>
>> According to current opentox.owl, a Feature can be assigned Algorithm,
>> Model or Dataset as its origin (via property ot:hasSource).   There is
>> no support for Algorithm + Parameters, except if the specific case of a
>> Model can be regarded as Algorithm + Parameter instance.
>>
>> One possible solution could be:
>> - define superclass A, which is determined by Algorithm + Parameters
>> - Make Model subclass  of A
>> - define  domain of ot:hasSource  as classes A and Dataset
>> - Find a nice name for the superclass A
>>
>> This will be searchable via ontology service.
>>
>> Question: Can we directly use Model to denote descriptors, especially
>> descriptors, which require datasets to be calculated?
>>
>> 3. Dataset API
>> Reminder: the dataset API 1.1 allows specifying feature URI and compound
>> URI on GET operations:
>>
>> http://opentox.org/dev/apis/api-1.1/dataset
>> Query a dataset 	GET 	/dataset/{id} 	*compound_uris[]* and/or *feature_uris[]* to select compounds and features;
>>
>> These are very flexible means to get slices of a dataset (features = columns, compounds = rows ), or merging data across different datasets, without the need to download/upload dataset content.
>>
>> However, there have been some concerns, regarding the length of the URL. The proposal is to extend the same approach to allow POST and PUT operations to specify datasets via dataset_uri, compound_uris and feature_uris.  
>>
>>
>> Create a new dataset 	POST 	/dataset 	
>> 	Dataset representation in a supported MIME type. MIME type to be
>> specified via *Content-type* header.
>> 	New URI /dataset/{id} or redirect to task URI (for large uploads)
>> 	200,202,400,503
>>
>> Update a dataset 	PUT 	/dataset/{id} 	
>> 	Data representation in a supported MIME type; entries for existing
>> compound/feature pairs will be overwritten, entries for new
>> compound/features will be added
>> 	Dataset or task URI
>> 	200,202,400,404,503
>>
>>
>> *Proposal: *
>> 3.1.  If MIME type is *application/www-form-urlencoded*, allow
>> dataset_uri , feature_uris[] and compound_uris[] are input parameter for
>> PUT and POST operations.    This will facilitate assigning new dataset
>> id to client specified subsets of data.  URL length is not an issue
>> anymore, since parameters are passed via POST content body.
>>
>> example: 
>> POST /dataset 
>> dataset_uri=http://myservice/dataset/1 
>> feature_uris[]=/selectedfeature1
>> feature_uris[]=/selectedfeature2
>>
>> 3.2.  For file uploads, agree on fixed name for file upload parameter
>> in  *application/www-form-urlencoded  *- e.g. *file_upload*. 
>> When uploading content other than RDF (e.g. MOL, SDF, SMILES), there are
>> currently no means how to assign metadata (even file name is not
>> available when POSTing content other than RDF).
>>
>> 4. Query API.  There is currently no agreed API on querying for   .
>> There are some custom implementations:
>>
>> Query for property/identifier  value
>> http://ambit.uni-plovdiv.bg:8080/ambit2/compound?property=CAS&search=50-00-0
>> <http://ambit.uni-plovdiv.bg:8080/ambit2/compound?search=55-55-0>
>> or
>> /compound?search=phenolphthalein
>> <http://ambit.uni-plovdiv.bg:8080/ambit2/compound?search=phenolphthalein>
>>
>> Proposal:  /compound?search=value&sameas=http://url_from_an_ontology , e.g.
>>
>>
>> /compound?search=50-00-0&sameas=http://www.opentox.org/api/1.1#CASRN
>>
>> Substructure
>> /query/smarts?search=c1ccccc1O&max=100
>> <http://ambit.uni-plovdiv.bg:8080/ambit2/query/smarts?search=c1ccccc1O&max=100>
>>
>> Similarity
>> /query/similarity?search=c1ccccc1&threshold=0.8
>> <http://ambit.uni-plovdiv.bg:8080/ambit2/query/similarity?search=c1ccccc1&threshold=0.8>
>>
>>
>>
>> AFAIK, IST implementation uses /compound/{id}  API , which seems
>> reasonable for first two cases, but there might be issues with embedding
>> non-ascii symbols in {id}  (e.g. InChI , Smiles)
>>
>> Best regards,
>> Nina
>>
>>
>>
>> _______________________________________________
>> Development mailing list
>> Development at opentox.org
>> http://www.opentox.org/mailman/listinfo/development
>>
>>     
>
>
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>