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

Sat Mar 3 08:59:01 EST 2012

On Mar 2, 2012, at 6:37 PM, Eric Rozell wrote:

> 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
> 

I'm REST-agnostic.  I'm happy just to use something that can be completely encoded in a URL, be it true REST or "REST/RPC-Hybrid", as the REST guys call it.  My use case is to be able to "easily" add this search into a variety of applications where the user is presented with a dataset and needs to also be presented with the tools that go with that dataset.  This includes our search interface (Mirador), various pages in our Website (where I love the idea of being able to embed the "search" as a URL), etc.

As for facets, I think we should strike a balance between need and complexity.  What is the minimum a user needs to know before deciding to follow up on a tool in more detail?  I would say that is pretty much limited to:
o  What dataset a tool works with, and what form the dataset needs to be in
o  What basic operations can it do with that dataset:  read, plot, map, analyze
o  What systems can it run on:  Linux, Windows, Mac OSX
o  Cost/License:  free, shareware, commercial

There's a bunch more stuff we *could* add, but 

> 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
>> 
> 
> _______________________________________________
> esip-semanticweb mailing list
> esip-semanticweb at lists.esipfed.org
> http://www.lists.esipfed.org/mailman/listinfo/esip-semanticweb

--
Dr. Christopher Lynnes, NASA/GSFC, Code 610.2, 301-614-5185