[kepler-dev] Displaying repository results in component search pane

[ben leinfelder]

Thanks for laying out the options, Sean.
I think option 1 is the most reasonable and feasible one at this  
point. KARs are the first-class search results and only contain  
entries that may or may not have semantic types. I think it helps  
cement the KAR-as-archive notion when we present it as a container of   
workflow[s] and report[s]. While it is possible to duplicate entries  
when multiple semantic types have been used, this is a problem we  
already face in the actor library and the local repository where  
actors can be classified in more than one category. Report layouts  
will not have any semantic types of their own and should just appear  
along side the workflows upon which they are based.
-ben

On Mar 12, 2010, at 2:05 PM, Sean Riddle wrote:

> Now that a given KAR file can contain multiple items (like a  
> workflow and a report), I'm trying to rethink the way repository  
> results are displayed in the component search pane so that relation  
> isn't lost. For instance, consider the following: There are two  
> items, a workflow W and report R, in a KAR file. A user searches on  
> the LSID of the KAR file, so both results have to be displayed. The  
> workflow and report have semantic types S_W and S_R, respectively.  
> At the moment, the system would display this:
>
> S_W
> |
> |
> --W
> S_R
> |
> |
> --R
>
> There's no hint that W and R are related. So here are a few ideas  
> for preserving that information.
>
> Option 1, I was thinking, is to introduce an extra top level to show  
> containment in a KAR file, like so:
>
> K
> |
> |
> --S_W
>     |
>     |
>     --W
> --S_R
>     |
>     |
>     --R
>
> The downside to this approach is that S_W and S_R could appear  
> multiple times if other search results in other KAR files share  
> those semantic types. This could clutter up the search results.
>
> Another option, rather than trying to overload a single tree with  
> this additional data, would be to introduce another mode for the  
> search result pane, where it just shows containment. In this case,  
> the semantic type mode would be what the system currently does, and  
> the containment mode would show the following:
>
> K
> |
> |
> --W
> --R
>
> Of course, this introduces the problem of the best way UI-wise to  
> switch between the two modes, etc. I think this would be good for  
> some point in the future, but not for 2.0.
>
> My preferred option, at the moment, is similar to what the system  
> does now. It relies a bit on the fact that from what I've seen,  
> reports don't get semantic types (Let me know if I'm wrong about  
> that). For the purposes of display, I figured give them the same  
> semantic type(s) as the actor/workflow (this assumes there is one),  
> and then communicate the relationship between the two through the  
> displayed name of the report:
>
> S_W
> |
> |
> --W
> --R (W report 1)
>
> So those are just some ideas I've been kicking around. Please reply  
> if you have a preference or other ideas.
>
> - Sean
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev