Hi Nina, 

  This is a way that Restlet suggests for encoding and parsing arrays of
parameters but in any case the parsing on the server side is
straightforward even without Restlet. I think what Restlet developers
had in mind was a URL that contains information for a multitude of
parameters, not necessarily being multivalued or vector-valued. They
also allow for default parameters in the URL. Our main concern though
has to do with the RDF representations.

Best Regards,
Pantelis

On Tue, 2010-10-26 at 17:15 +0300, Nina Jeliazkova wrote:

> Hi,
> 
> Not sure if it is relevant, but have you considered Matrix URIs (there is
> Restlet support for these)
> 
> http://blog.noelios.com/2008/05/20/restlet-11-m4-released/
> 
> http://www.w3.org/DesignIssues/MatrixURIs.html
> 
> Best regards,
> Nina
> 
> On 26 October 2010 17:09, chung <chvng at mail.ntua.gr> wrote:
> 
> > Dear all,
> >  While trying to implement the consensus modeling services we realized
> > that the POSTed parameters are multivalued while this is not supported
> > by the current API. In particular, users need to post pairs of
> > predictive and domain of applicability model URIs as one parameter
> > instead of two. We examined the possibility of accepting two lists of
> > parameters, namely one list for DoA models and a list for predictive
> > ones but this caused various problems in the RDF representation and in
> > the consistency of the service API. This raises questions about the
> > efficiency of the efficiency of ot:Parameter in such cases as well as in
> > cases where one needs to post  an array of parameters of the same type.
> > So the following cases have to be taken into account:
> >
> > 1. Posting a vector-valued parameter:
> > curl -X POST -d param1="value1=15,value2=5"
> > http://someserver.com/service
> >
> > 2. Posting an array of parameters (of the same type), i.e.
> > posting the array  xyz[] = {1,3,5}
> > curl -X POST -d  xyz[]=1 -d xyz[]=3 -d xyz[]=5
> > http://someservice.com/service
> >
> > 3. Posting an array of vector-valued parameters:
> > Here we need to post an array of two vectors: array[] = {[7,8], [9,10]}
> > curl -X POST -d prm[]="value1=7,value2=8" -d prm[]="value1=9,value2=10"
> > http://someserver.com/service
> >
> > Obviously the problem exists because URL-encoded parameters posted as
> > application/x-form-url-encoded were not design to support so complex
> > data, so we either have to adapt to it as we explained above or we have
> > to find some other (more complex) way to provide these information to
> > the service such as POST the request as XML or JSON. The latter will be
> > inevitable if the client has to post a matrix to the service as a
> > configuration parameter.
> >
> > >From the RDF point of view, we also need some extensions to be able to
> > represent the abovementioned data structures. So for arrays of
> > parameters we suggest to have just an indexing using the ot:index
> > property. For example:
> >
> > http://sth.com/algorithm/abc
> >  a ot:Algorithm
> >    rdfs:comment "myParam[]={100,200}"
> >  ot:Parameter [
> >        ot:index 1
> >        dc:title "myParam"
> >        ot:value "100"^^xsd:int
> >  ]
> >  ot:Parameter [
> >        ot:index 2
> >        dc:title "myParam"
> >        ot:value "200"^^xsd:int
> >  ]
> >
> > No indices should be skipped.
> >
> > For vector valued parameters we can make use of ot:Vector. Here is an
> > illustrative example:
> >
> > http://sth.com/algorithm/abc
> >  a ot:Algorithm
> >  ot:Parameter [
> >        dc:title "myParam"
> >        ot:value [
> >                    a ot:Vector
> >                    dc:title "xyz"
> >                    rdfs:comment "xyz=[1.274, -4.823]"
> >                    ot:vectorElement [
> >                        a ot:VectorElement
> >                        ot:index "1"^^xsd:int
> >                        ot:value "1.274"^^xsd:double
> >                    ]
> >                    ot:vectorElement [
> >                        a ot:VectorElement
> >                        ot:index "2"^^xsd:int
> >                        ot:value "-4.823"^^xsd:double
> >                    ]
> >                ]
> >  ]
> >
> > Best Regards,
> > NTUA Development Team
> > _______________________________________________
> > 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
>