[OTDev] Questions to feature generation and feature selection

Nina Jeliazkova nina at acad.bg
Fri Jan 15 13:33:26 CET 2010


Hi Tobias,

Tobias Girschick wrote:
> Hi Nina,
>
> in one of your previous mails to Fabian you gave this return URI:
>
>   
>>> http://ambit.uni-plovdiv.bg:8080/ambit2/dataset/37?feature_uris[]=http://ambit.uni-plovdiv.bg:8080/ambit2/dataset/37/feature&feature_uris[]=http://ambit.uni-plovdiv.bg:8080/ambit2/feature/29658&feature_uris[]=http://ambit.uni-plovdiv.bg:8080/ambit2/feature/29659
>>>       
>> [...], I should return the long URL upon upload. 
>>
>>  In fact one can construct wide variety of datasets, combining features
>> from several existing ones via feature_uris[], without anything
>> physically copied.
>>     
>
> I have some questions concerning this. First of all, don't you think we
> might run into problems with URL length limits (theoretically
> non-existent but practically at 2 - 190 thousand depending on the server
> or browser)?
>   
You are right, this is actually API issue - how do we handle
restrictions on the URIs.  Without losing flexiblity,  I can see couple
of ways
1) retrieving same information via POST (then the parameters will be
inside the www-form , instead of URI ), but we'll deviate from REST best
practice.

2) Introduce a separate resource, where one can create groups of
features for later reuse :

GET /feature_list/{id}   can return 
/feature/1
/feature/2
etc

POST /feature_list   will accept uri-list or RDF and will create new
group of features
PUT /feature_list/{id}  will update the list
DELETE  will delete the list

 then the dataset URI might be reduced to

http://ambit.uni-plovdiv.bg:8080/ambit2/dataset/37?feature_uris[]=/feature_list/mylist_of_selected_features  

(there is no restriction that feature_uris[] contains a single feature, any number will do)

> Second, isn't the first part of the URI sufficient? (Here it is the URI
> that is returned upon a POST of a dataset to /dataset that has been
> submitted for descriptor calculation).
>   
For completeness of the URL, and avoiding errors, I would prefer to
avoid splitting. 

Bets regards,
Nina
> best regards,
> Tobias
>
>
>
>   




More information about the Development mailing list