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.htmlmisc
http://www.w3.org/1999/11/11-WWWProposal/rdfqdemo.html XRI / XDI
Nongo/Congo
Rails 2.0 Rest