Design+braindump

From Datastructure conversation:

what we want to capture:  how can we make building complex relationships simple & clean

field v. tag
3-way relations:  A+B=C  vs.  (A+B)+C
Natural language:  subj, verb, obj
Arrays
Pointers
1 to 1/ 1 to many/ many to many
distributed data

temporary notation:

A+B=C    for case where content of A+B is a pointer to C

 



From session on 2007-07-11:  Some of the ideas that came up-- each of these are big areas for exploration:

• Expanding [Default cardtypes][Default_cardtypes]
• A way for multiple people to give structured input on something and then do operations on everyone's input. This might look like John Abbe+Open Space+rank, Lewis Hoffman+Open Space+rank, etc., all datatype number, then some way to get averages etc. (was personal cards  ie. "Me" tagging)
• 3-way relationships, ie.  (user) John, (practice) OpenSpace, facilitation-- you want to take any two and see the third.
• plus-card input box for query cards (search interface) [John and Linnaea called this "query on + cards" but i can't remember what it means]

----

 
Queries I want
    cards with biggest "trees" under them
    "orphans" cards with no links (or connections?) to them
    cards with most connections
    


editing outline datatype

transclusion
  via DOM/Ajax -- enables cut-n-past

areas of inquiry
    defaults
    tracking software ideas
    search urls

testing testing testing  


ruby cards
  why's sandbox
  ruby template cards
  Tepee wiki  
 

query cacheing
    need a mechanism of marking which kind of queries can be cached
         (relationships) and what operations break the cache.  for example
                                  
         query                                                                            changes on
         -----                                      -----------
         plus_cards, plussed_cards                  new connection
     backlinks                                                                    link creation
     user_edits                                                                    user_edit
     pieces                                                                            rename

  cached query key consists of
         options hash
        "virtual user group" key made by sorting the ids of all the groups the user is in--
                thus permissions should be the same for anyone in the virtual group, and we can
                cache the results for the whole group.  
         don't break cache needs broken when permssions change--
              skype
        cards still come back with results, just not viewable..?  
        wow the granularity of permissions makes this really hard... :-(
                


in-browser result refinement
    like kayak.com interface
    load large result set into browser
    refine search via javascript, ie TrimQuery
    pros
        standardize base queries easier to cache
        paging and filtering etc. more responsive
        paging and filtering place less load on the server.
    cons
        sorting can't really be done properly..

    refs
        http://codinginparadise.org/weblog/2005/10/javascript-sql-database-with-permanent.html
        http://trimpath.com/project/wiki/TrimQuery  
    


sparql query langauge                                                      

    http://www.oreillynet.com/xml/blog/2005/09/sparql_web_20_meet_the_semanti.html

misc
    http://www.w3.org/1999/11/11-WWWProposal/rdfqdemo.html

    XRI / XDI
    Nongo/Congo
    Rails 2.0 Rest