pcplantdb

[Stephanie Gerson <sgerson@stanfordalumni.org>]

whoa.  Not sure if I completely understand what yalls are discussing 
here, but it sounds like your mimicking my vision for the front-end (webs 
of webs, relationships of relationships) with the backend.  Beautiful.  
Of course, rewinding all the way, we are ultimately mimicking the 
ecological webs themselves...

Anyhows, I like what Lawrence wrote:
"Maybe this is a matter of orchestrating, coordinating massive amounts of 
table lookups with one result of this process being that seemingly 
unrelated information can be viewed by a user wishing to discover new and 
possibly previously hidden relationships between things. Maybe you would 
have tables of tables as with columns of attributes-as-other-tables."

Imagine!  A database that not only allows you to learn about 
relationships, but discover ones that you (and others) didn't even know 
existed!  Discovering the infinite interconnectedness between 
everything...ok I am starting to sound like Dr. Brauner's but you dig it, 
ya?

pace bambinos
*s

"Lawrence F. London, Jr." <lfl@intrex.net> wrote:

John Schinnerer wrote:
> Aloha,
> 
>> Can you provide a layman's explanation of ORM with MySQL and what the 
>> default/alternative would be?
> 
> 
>> What are the advantages offered by ORM as the object-oriented 
approach?
> 
> 
> I'll leave these to Chad - he is more familiar with details of this 
> stuff than I am.
> 
>> Whhat does object-oriented mean in the ocntext of what we are doing 
>> and how does it fiffer from non-OO methods?
> 
> 
> There's been a lot of posts on this already - check the archives for a 
> reprise.

Thanks for posting this, John; it clears up a lot of confusion.

> IMO an object model for our project is much more appropriate than a 
> relational-database model.
> 
> Plant objects (stored in an object DB) would contain information about 
> themselves and ways ('methods', meaning essentially bits of code) to 
> share than information.

How do those bits of code (each possibly a microcosm of other bits of 
code
as with plant taxonomical data) communicate with other bits of code 
"attached" to
other objects, i.e. other plants, microfauna, microflora, mammals, birds, 
reptile objects,
guild objects, pc systems objects (i.e. landforms involving weather 
exposure, soil, water,
stone, wood, manade materials), water, soil, etc.

> This is essentially what real-world plants do - they 'know' about 
> themselves and communicate with other entities in a variety of ways - 
> colors and scents to attract pollinators and/or repel predators, root 
> exudates to attract symbiotic micro-fauna or scare off predatory 
> micro-fauna, and so on.

Just rambling - this is getting interesting.

This may be boring to the programmers but possibly useful to other 
laymen.
Trying to think of an image that describes this real world system in 
software terms.
I envision for the object model as a ball covered with stickum on a pole 
in the wind
gathering information debris. Each piece of debris can send semaphore-
like signals to
other balls each with their own unique debris-array.

I'm trying to relate this to a touchgraph-like display and what happens 
when negotiating
or navigating your way through one.

> In a relational-DB model, plants are abstracted as tables of 
information 
> 'about' plants, with columns identifying general 
> attributes/characteristics of plants and rows containing specific 
> information on particular plants.
> Instead of simply asking a plant object about itself in various ways, 
> queries have to be constructed to de-abstract the abstractions created 
> in making the tables, in order to extract the desired information 
> 'about' the desired plant or plants.

Maybe this is a matter of orchestrating, coordinating massive amounts of 
table lookups
with one result of this process being that seemingly unrelated 
information can be
viewed by a user wishing to discover new and possibly previously hidden 
relationships
between things. Maybe you would have tables of tables as with columns of 
attributes-as-other-tables.

> Either approach can be made to do what we want.
> I think the relational databse approach will get really really nastily 
> complex and hard to work with as we add complexity to both tables and 
> queries.
> 
> The object-oriented approach just seems way more appropriate - simpler, 
> more like what we are trying to model.

> We are already a culture addicted to abstraction; I think plant objects 
> in an OO database are less an abstraction than relational database 
> tables full of bits of data about plants.

Can you explain this a little further?

Thanks,

LL
-- 
L.F.London
lfl@intrex.net
http://market-farming.com
http://www.ibiblio.org/ecolandtech
_______________________________________________
pcplantdb mailing list
pcplantdb@lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/pcplantdb




+++++++++++++++
Stephanie Gerson
sgerson@stanfordalumni.org
(c) 415.871.5683


____________________________________________________________________