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

[Chad Berkley]

I agree with Ben.  I think it's probably fine that the object appear 
more than once.  We already do that in the actor tree if an actor is 
tagged with more than one semantic type.  The report should definitely 
appear with the workflow which generated it.  I don't think it makes 
sense to separate them.

chad

ben leinfelder wrote:
> 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
> 
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev