From CWRC


Revision statistics per user
User Total #
of edits
Sentences Links
Owned Proofread Deleted internal external
current total current total sentences releases current total current total
SusanBrown 1 35 35 0 0 0 0 0 0 0 0
    
Page statistics (latest revision)
StatisticValue
Edits (last 30 days) 0
Edits (total) 1
Incoming Internal Links 0
Page Views 1009



Skype meeting: Denilson, Patrick, Susan, Tyson

Patrick summarized what he's garnered so far from looking at the data and code of the Orlando viz tool: it's been loading the entire file into memory; drawing on libraries for loading and parsing it wd speed things up a lot, and allow it to be modular and therefore, when needed, parallelized so that sep jobs could be parsing the file

Denilson summarized what he has been doing with his social network viz tool system, Reason, which is to decouple back from front end, modularize etc. in very much the same way we are thinking needs to be done for the Orlando viz tool The pieces:

  • relational db stores both data and bibliometrics (calculate once and store for future use); data can be updated cell by cell and recalculated as needed

system is data agnostic: will take in range of forms of data so long as expressed as nodes and edges including graphML

  • using new version of Flex and Flash (birdeye - code.google.com/p/birdeye/ ) that run faster than previous versions
  • SOA: all viz is web-based; data computed, cached, and sent from db to browser as needed; front end basically all PHP
  • user defines smaller networks based on criteria they set

Reason's workflow also includes taking in data, cleaning, removing duplicates, etc.: this may be useful for CWRC down line, when people will want to pull in/upload other materials than stuff resident in ORCA db

Orlando data to use reason would need to be defined in terms of Reason's terminology, but this is probably pretty easy to do with the semantic markup

Denilson needs more work on network analysis algorithms; Orlando tool needs that too: one possible area of collaboration in longer term: caching works right now on web server level but the analysis for all communities in larger data sets is going to be computationally intensive enough that the queries could be handed off to HPC for analysis; don't want to do that analysis w/i the dbase

network analytics in Java Patrick wants to keep Orlando viz tool in c/c++

Timeline: Would probably be too much of a push to try to really bring the two systems together by late Sept when we would hope to be doing some user testing; easier to share components at this stage? e.g. Denilson cd package up the visualization quickly


TO DO:

  • Susan to send Patrick degrees of separation use cases (and put up on the wiki)
  • Jeff to get Patrick full set of data that the viz tool has been using (what he has is cut off)
  • Jeff also to send P all the data we would like to use, so the biblio, events material as well as entries (in long term we want this stuff to be accessed through the API so we are using fresh and not stale data)

NEXT STEPS:

  • Meeting Wed at 3pm 28 July: Mike, Tyson, Patrick and Susan to talk re: how to formulate detailed resource allocation proposal to Sharcnet
  • Meeting Wed, 4 Aug afternoon (time TBA), of Jeff, Patrick, Tyson, Denilson, Susan AND ANYONE ELSE WHO WANTS TO JOIN US, via Access Grid, to discuss next steps, API, etc. There are remote AG apps available if you don't have access to an AG room and want to participate.

QUESTIONS: Can we fit Mark (who is going to be working up an experimental viz prototype) usefully into this process somehow, and have him build the viz prototype using this back end? or would that get too complicated? Jeff can advise on this once back. Consideration is desire to have something working to test in fall. Could just try to speed up what we have with use of libraries and see if that would be enough of an improvement in speed to get feedback on current interface.