permaculture

[Paul Cereghino <paul.cereghino@comcast.net>]

I think you should go for it... but heed Jedd, creep slowly... this 
sounds like a potential project mangement nightmare... once you start 
populating the RDB you get locked in.. most databased fail for lack of 
conceptual design. You need to fully conceive and test the structure of 
your information before you open the flood gates.
I think I get what you are talking about -- but don't know much about 
RDB... what about something more conceptual like:

tbl_element: (element_id, element_name, element_family (lookup),
tbl_elementattribute_link (element_id, attribute_id)
tbl_attribute (attribute_id)
tbl_attribute linkage (attribute1_id, attribute2_id, l

elements are physical components of a system (i.e. wind tower, chicken, 
worm box, absorbtionswale, building wall, building roof). They would 
have to be clearly defined, explicit, mutually exclusive. You'd have to 
be able to split elements that got to loaded... for example, swale 
becomes, absorbtion swales vs. diversion drains vs. drainage ditches, etc.
Are individual species elements?! this would go too far perhaps... maybe 
functional groups are better. How could designers interact that are in 
different climates... what if elements have different attributes based 
on climate?! You could have biome independant attributes and biome 
dependant attributes or you could just qualify linkages
It would have to be a nested taxonomy of elements... there are 
relationships between 'building' attributes and other elements... then 
there is 'metal roof' vs. 'living roof' vs. 'brick wall'...

design elements have attributes attributes, there are different types of 
attributes,
beneficial inputs (element process improves)
processes (element does some function/work/process)
outputs (element produces output)
contraints (element doesn't function in presence of condition)

elements have multiple attributes, attributes create linkages between 
design elements. You could search for potential linkages be looking for 
similar attributes where one is an input and the other an output. You 
could search for contraindications by avoiding outputs and constraint 
similarities.

Y'know... even just developing the element input/output analysis 
collectively would have tremendous value... and that could be done by 
simply aggressively structuring an existing Wiki. Fleshing out a range 
of elements in terms of their permaculturally significant attributes 
would be a good preliminary exercise to better define the nature of the 
data structure that would be of service.

Paul


>  
>
> > -say for a wind turbine generator installation:
> >
> > windProject table: 
> > ( rowID, projectID,projectName, longitude, latitude, windZone, expectedDaysUseableWind,towerHeight,towerMaterialConstruction,testedVAOutputAvg)
> >
> > windMeasurement table: (rowID,projectID,dateMeasured,measuringTowerHeight,timeMeasured,avgWindSpeed ) 
> >
> > windTurbine table:
> > (rowID,projectID,turbineType,turbineMake,turbineModel,minWindSpeed,minOutput,maxWindSpeed,
> >  maxOutput,turbineWeight,turbineDimensions,turbinePropDimensions)
> >
> > whatcha think?
> >
> > negiliblek
> >    
>
> Looks wonderful; I will put you in touch with the server staff so we can get 
> going.
> Other considerations:
>
> A name for this project.
>
> Do we want a .org, .net or .info domain and have that hosted instead of using 
> the server's name?
>
> I'll donate a domain for 3 years if that's the direction we want to take.
>
> Some sort of peer review process to filter data entered; or a ranking system 
> to evaluate data quality and usefullness
> A registration or user authentication component as we will not want anonymous 
> data entry
>
> LL
>