[esip-semanticweb] posted initial version of ToolMatch data model

[Eric Rozell]

What's the use case for making this a REST service?  Any particular reason for not making the ToolMatch service as simple as possible (using just URL parameters...)?  If the use case is "reusability", we will hopefully keep all the metadata as RDF and make it available via SPARQL and Linked Data (which is REST-ish).  When it comes to the ToolMatch service, the service should only be as complicated as it needs to be to implement the UI.  Which brings me to my next point...

Chris and Hook bring up some good use cases.  What are some of the other features that a good ToolMatch UI would have?  Should there be a facet for system compatibility (i.e., operating system), a facet for the "tool purpose" (i.e., visualize, map, analyze, cluster, etc.)?  These are the kinds of use case questions we need to factor into the ToolMatch data model.

Any thoughts?  Dataset ID, System compatibility, and tool purpose are a good start.  Any others?

--Eric

On Mar 2, 2012, at 3:53 PM, Hua, Hook (388C) wrote:

> 
> 
> On 3/2/12 12:10 PM, "Lynnes, Christopher S. (GSFC-6102)"
> <christopher.s.lynnes at nasa.gov> wrote:
> 
>> 
>> On Mar 2, 2012, at 1:42 PM, Mattmann, Chris A (388J) wrote:
>> 
>>> Hi Guys,
>>> 
>>> On Mar 2, 2012, at 6:18 AM, Lynnes, Christopher S. (GSFC-6102) wrote:
>>>> 
>>>> In addition, machine level code might do this as well, in which case,
>>>> the REST-like URL might look like:
>>>> 
>>>> http://toolmatch.esipfed.org/findtools?doi=doi:10.1594/PANGAEA.695832
>>>> http://toolmatch.esipfed.org/findtools?gcmd_dif=GES_DISC_AIRX3STD_V005
>>> 
>>> In the above scenario, I'd advocate for:
>>> 
>>>> http://toolmatch.esipfed.org/findtools/doi/10.1594/PANGAEA.695832
>>>> http://toolmatch.esipfed.org/findtoolsgcmd/dif/GES_DISC_AIRX3STD_V005
>>> 
>>> 
>>> Those are inherently more RESTful, and path parameter based.
>> 
>> OK, but no fair stopping with the easy one :-), you've got to add in the
>> additional query parameters we'll eventually have as RESTful path
>> segments:
>> 
>>>> 
>>>> http://toolmatch.esipfed.org/findtools?doi=doi:10.1594/PANGAEA.695832&ma
>>>> ps=true&os=linux
>> 
>> becomes....
>> 
> 
> 
> Many REST service frameworks support RESTful dispatching of the request
> query parameters. CherryPy and JAX-RS are good examples. That is, the set
> of parameters
> 
> http://toolmatch.esipfed.org/findtools?doi=doi:10.1594/PANGAEA.695832&maps=
> true&os=linux
> 
> 
> would be (with encoding the "/" in the DOI)
> 
> http://toolmatch.esipfed.org/findtools/doi/10.1594%2FPANGAEA.695832/maps/tr
> ue/os/linux
> 
> 
> 
> But when you look at some practices in RESTful URLs with dispatching verbs
> [1], the verb is moved to the end to follow the spirit of RESTful
> resources. So:
> 
> verb.cgi?restype=type&resid=id
> 
> would become:
> 
> 
> /type/id/verb
> 
> 
> 
> Does that mean our URL example would be the following?
> 
> 
> http://toolmatch.esipfed.org/doi/10.1594%2FPANGAEA.695832/findtools
> 
> And as Chris L. was saying with the need for query parameters, would it be:
> 
> /type/id/verb/{parameter pair verb modifiers}
> 
> http://toolmatch.esipfed.org/doi/10.1594%2FPANGAEA.695832/findtools/maps/tr
> ue/os/linux
> 
> 
> Sometimes doing things the really formal way may not the most
> user-friendly way.
> 
> --Hook
> 
> [1] http://tools.cherrypy.org/wiki/RestfulResource
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> esip-semanticweb mailing list
> esip-semanticweb at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-semanticweb
>