Slides from talk on FluidDB to #geomob by Terry Jones in London on Jan 29, 2009.

1. FLUID DB
The database with the heart of a wiki
Terry Jones
terry@jon.es

2. TWITTER
terrycojones
fluidDB

3. VAPORWARE
ALERT

4. CONCEPTS

5. do not require permission
allow the unanticipated
have no formal structure
are not owned
may be multiply organized
CONCEPTS do not have predefined qualities
have no central piece of content
no data/metadata distinction

6. RETHINK
CONTROL

7. how can we search & on what?
must we anticipate? the dark side of UI
RETHINK who owns information?
CONTROL
must we ask permission?
how do we create & add to information?

8. WRITEABLE

9. SIMPLE

10. MOST
IMPORTANT

11. OBJECTS HAVE
NO OWNERS

12. yep, no owners
OBJECTS HAVE
NO OWNERS
none

13. OBJECTS HAVE ATTRIBUTES
ATTRIBUTES HAVE OWNERS

14. OBJECTS HAVE ATTRIBUTES
ATTRIBUTES HAVE OWNERS
and permissions

15. QUERY LANGUAGE
Numeric: attribute value (=, <, etc.)
Textual: attribute text match
Presence: has attribute
Grouping/logic: (...), and, or, not

16. COOL
FOR
CODERS

17. MASHUPS

18. server design API #3
learn API #1 fetch
mash database document it
learn API #2 fetch
tables keep it up
scale it
MASHUPS

19. server design API #3
learn API #1 fetch
mash database document it
learn API #2 fetch
tables keep it up
scale it
MASHUPS
use FluidDB:
fetch from fluidDB
mash
store to fluidDB

20. MASHUPS

21. don’t build more hoops
MASHUPS
put info where it most naturally belongs
with the object it’s about
use same API

22. LEVEL PLAYING FIELD

23. data
LEVEL PLAYING FIELD
^

24. no-one sets the rules
control
data
LEVEL PLAYING FIELD
^
freedom
you can arrive late

25. ORGANIZATION

26. just more information
weinberger
ORGANIZATION
where to put new info?
all organizations can co-exist, no interference

27. DATA
STRUCTURES

28. structs and pointers
DATA
STRUCTURES

29. structs and pointers attributes and search
DATA
STRUCTURES
build ‘em on the fly yep, all of ‘em
slow.... but infinitely flexible

30. SWEET SPOT

31. a few attributes
small apps
SWEET SPOT
social data
architecturally aligned

32. a few attributes
small apps
SWEET SPOT
mobile? social data
architecturally aligned

33. USERS have a corresponding object
ATTRIBUTES do too
DOMAINS ditto

34. USER
INTERFACE

35. Can I search? On what?
where did my information go?
USER
Is there an API?
Wouldn't it be cool if...
INTERFACE Can I extract, re-use, add, delete?
Special pleading

36. UI
API

37. positive
helpful
UI
friendly
enabling
API
empowering

38. positive
restrictive
helpful
UI
friendly
controlling
enabling
API special purpose
empowering
necessary?

39. PERSONALIZATION

40. in our hands, not on our behalf
protect, share, delete as you wish
PERSONALIZATION
organize as you please
add anything to anything...
and search on it

41. EVOLUTION

42. fitness of competing solutions
of trust
of reputation
EVOLUTION
dynamics of spam of convention
will fix inefficiencies (if they’re worth fixing)

43. REPRESENTATION

44. representation choice
is part of problem solving
REPRESENTATION
a good representation
may not need a smart algorithm

45. Alan Kay
At PARC we had a slogan: “Point of view is worth 80 IQ
points.” It was based on a few things from the past like
how smart you had to be in Roman times to multiply two
numbers together; only geniuses did it.
We haven't gotten any smarter, we've just changed our
representation system. We think better generally by
inventing better representations; that's something that we
as computer scientists recognize as one of the main
things that we try to do.

46. 1
1
10
2
100
4
1000
8
10000
16
100000
32
1000000
64
10000000
128
100000000
256
1000000000
512
10000000000 +
1024 +
?????? 11111111111

47. VIII
XVII
XLIV
LXXX
XCVI
CCLV

48. VIII
XVII
XLIV
LXXX
XCVI
CCLV +

49. VIII
XVII
XLIV
LXXX
XCVI
CCLV +
D

50. VIII
XVII
XLIV
LXXX
XCVI
CCLV +
D

51. 8 QUEENS PROBLEM
Use a poor representation with 264
(281,474,976,710,656) states
Look for a smart algorithm!
OR...
Use a good representation with 8! (40,320) states
and exhaustive search as an algorithm!