[seek-dev] Re: Thoughts on data input into Kepler: and 'R'

[Bertram Ludaescher]

>>>>> "SB" == Shawn Bowers <bowers at sdsc.edu> writes:
SB> 
SB> Matt Jones wrote:
SB> 
>> I also agree that we'll need alternative ways to view the data than just 
>> chunking it up to one record per fire.  We've discussed 'table at a 
>> time' delivery and your suggestion of being able to output 'vector at a 
>> time' delivery is also a good idea.  Both R and Matlab are more vector 
SB> 
SB> This is off topic, but shouldn't "table-at-a-time" basically be the 
SB> default way to pass relational data in a workflow system such as Kepler? 
SB>   It seems like any sort of statistical operation (except "non-blocking" 
SB> ones) or operations that combine (i.e., joins) two or more datasets 
SB> requires table-at-a-time processing.

I tend to agree: unless we talk about streaming sensor data (which
SEEK might do at some point), most operations might be table at a
time.

But Matt's concern on scalability is also valid (see next mail)

Bertram

SB> 
SB> 
SB> shawn
SB> 
SB> 
SB> 
SB> _______________________________________________
SB> seek-dev mailing list
SB> seek-dev at ecoinformatics.org
SB> http://www.ecoinformatics.org/mailman/listinfo/seek-dev