Permaculture information technology: existing databases and design application efforts

Howdy,

This thread is a branch from Modularizing Permaculture: The Lego Method to discuss what information technology exists or is currently being developed by permies for permies. Much of the discussion so far has been on databases, but there is also some information on existing design applications.

The information below was initially posted on the thread above, but should now be discussed here. That thread is now being reserved for the non-technical discussion of modularizing permaculture.

-------

I suppose first off we should have everybody post exactly what they've accomplished so far and what their end goals are. The reason I say this is because many of us have started down a similar path, but where we wind up might be quite different. Although this may be the case, we have a lot of common needs, specifically in regard to a database.

For example, I'm not sure what Mike Hagar's database looks like, but I need a database that essentially represents the functional analysis of a plant. As such, Practical Plants has an infrastructure that seems to be aligned with mine. This has been echoed by others in the forum to be a preferred way to organize the data. So what I need is contact with Andru Vallance and access to the practical plant API.

On another note, I quite support Mike Hagar's comment about the internet not being a reliable resource. We're concerned with sustainability, and as such we should be applying permaculture principles to how we're designing technology for our community... right?! So, in the case of collapse or crisis our technology should continue to be useful... we can call it adaptable, and in the mean time we should be working together to achieve as much good as possible. I can see we're on track and that makes me quite happy.

Ok, so lets get to work. I propose each of us who are already developing some form of information technology list what their goals are, what their application specs are, and what progress we've made.

Given this information we will be equipped with the knowledge to align our forces in the most beneficial and effective ways.

I'll go first:

GOAL STATEMENT:

My goal is to create a tool that helps users organize and visualize the information needed to plan a perennial guilds / small-scale food forests for surburban settings in effort to rip out the lawns and put in edible and sustainable landscapes.

A lesser goal, although also important, is for this to be robust enough and well thought out enough to serve as my PhD dissertation research in computer science. It should be noted that development of such an application is worthy of several dissertation projects, so collaboration with all of you fits perfectly with in this requirement.


SPECIFICATIONS:
1. Suggests plants / rule plants out : this was a request of some of our senior permies and permie educators. Their reasoning was so that students and newbies had it as an aide / learning tool. Furthermore, it could encourage seasoned designers be variable in their plant selection, not automatically defaulting to their go-to species. Suggesting plants and ruling them out are dictated by the constraints of the site and the clients needs, as well as the key species that support the users needs.... you all know the drill.
2. Visualize client / user needs fulfillment in design process : This goes with the point made above.
3. Instruction on the permaculture principles : For those who come across this who aren't permaculture designers, they're gonna need to know why they're doing what they're doing.
4. Design canvas : This is the meat and potatoes. Complete with ability to modularize designs, visualize site analysis, and of course place plants for a design.
5. Collaborative Opportunity : Need to see what your neighbor has done so that you have added context to your design. Although whats over the fence may be out of sight, it should not be out of mind. Furthermore, there should be ability to borrow components of other's designs. Again, why require people re-create the wheel.
6. Produce an implementation plan

There are a lot more details to our design, but these are the big requirements.

PROGRESS:
1. Database designed, but little data inserted. On hold to see if we could grab data from another resource.. then we found practical plants! I'm waiting for a response from Tiny Mighty.
2. Prototype of canvas up and running - presently using javascript and html5. Runs in browser, doesn't require internet, but is augmented with data from internet. Basically it is better if you have the internet then if you don't. Not a big surprise there. Currently developing means to create a visual site analysis.
3. Interaction design for guild/food forest design underway. This is the stuff that decides how the design process goes down in the application.

I can already see several differences between my app and what some may want. For example, I'm not including animals for production purposes (human needs) because my scope is for suburban sprawl places which are already battling home owners association that forbid the growth of food in the front yard. I can very much see my envisioned application being expanded to incude animals, but because we're only five people right now just working with plants is plenty. Collaboration could change that.

---
In summary, we're still early in our development, but our team of 5 here at UC Irvine is working on it and each week we make a good amount of leeway. We're on schedule to keep this up through the end of March, then start back up in late April. As I said above, I'd love to collaborate with anybody who has already started working on something like this or wants to get involved. I'm not eager to re-make parts of technology that people have already essentially built, but instead I'd like to apply your efforts to achieve a greater goal and thank you tremendously for playing your part.

I look forward to seeing everybody's explicit goal, specifications, and progress.

Juliet

Edited RE-POST FROM Modularizing Polyculture - The Lego Method : https://permies.com/forums/posts/list/40/19849#174429

I have been visualizing and modeling a software suite to accomplish much of what everyone has been talking about for decades. For what it is worth I have spent 43 years as a software developer, project manager, architect and IT Director for government, aerospace, schools, corporations (Microsoft, KPMG) and many others. I am retiring to a 2.4 acre home that I hope to build into a Permaculture Food Forest.

My niche is developing multi platform business applications that can stand alone without outside web connections, connect and share data via IP (Web). In my opinion for a system to be resilient and helpful when it counts the most, the historical golden data of what you do on your place must be kept on a database on your machine. Nowadays many web developer feel that everything can be done on the web. Mother Earth News and others have Gardening software you can use for a reasonable monthly or annual fee. However if you loose your web connection for whatever reason, you have lost everything you have built.

The other side of this coin is that the world is full of data on plants and soil in general and specifically which nurseries in your town have the best stock of trees that are regionally hearty.

I mention this because once you get the basics of information about plants and what works together in general for your Climate Zone, building community communications and information sharing about what works in your Micro-Climate and who in town sells the best trees could be equally valuable.

I would like to start off by discussing an overall vision of the potential layers and platforms to support an optimum Permaculture Information Sharing system. The system that I would like to see grow has multiple modularized layers that can be build seperately yet have value on their own. I am ordering them in a hierarchical way not necessarily a "What comes first" way.

• A Centrally available Structured Database in the Cloud (fancy cool term for on the Web) would be a core layer.

The schema should be kept open and provde two interconneted layers. One would be a simple expression of the information that most people need to get going. Plants, nutrition requirements, provided nutrition, climate zones and polyculture connections. The addtional layer would support the additional data elements of greater interest to experts and researchers. The could come later and be generally (or initially) masked as to not intimidate. This database would provide a simple API to allow for connections with other sites to harvest information and shape it in ways that can be uniformly used by other systems. A clearing/cleansing house of sorts.

• The next Layer might be a Social Networking site template for Local Permies to share information on local plants resources that have proven valuable in their local micro-climate(s).

In my case I live barely outside of Spokane, Washington in a valley that is a winter cold pocket 10 degree colder than gardeners 2 miles away. This website would provide many "yields" by helping people to organize classes, meetings, community events and share local plant and planting tips with people they know. Buy local, teach local, learn local, share globally. To this end I am working on a replicate-able template at www.SpokanePermaculture.org. Each community portal could have connections with the centralized cloud based database and to Recommended Regionalized subsets of that data that will emerge over time based on local feedback.

• For each gardener (or farmer) we would need a similar, but not exact Client database would be installed as part of an application on a User’s personal computer.

This would have the same simplified core data schema with additional tables and fields that are only signification to them. Which of the plants (from the cloud but recommended for my local permie-buds) do I think I want (apples, berries and broccoli)... eventually? What supporting plants are recommended? Ok now which will I plant this year (rome wasn't built in a day)? What is my purchase list with local estimated costs? What is the seed, start, plant schedule FOR MY HOUSE AND PLAN? Who do my local permi-buds recommend to buy from? ...etc.

• At that point another option, at greater cost in time and money, but providing a greater visual tool to image where and when and how it would look... it would be great to have access to garden/farm 3D modeling system.

These tools are available but can be expensive. Creating them from scratch as on open source project would be tough. We don't expect our farmers or road builders to work for free. Let's find existing software that we can negotiate data interfaces with that can model our data visually. I am currently trying to sweet talk my way into this conversation with Idea Spectrum (http://www.ideaspectrum.com/rls_pro_overview.php). I am using their RealTime Landscaping Pro 2011 to model my project and that of another local Pemie-bud. It takes a lot of time and yes you can draw it out on a napkin or graph paper but after awhile the eraser tracks wear through the paper. At $100 the Pro version is well worth it for me but I am sure not for others.

However if there was a system that would allow all the layers above to create a plant import list (with pictures) that you could then place on your property or plot, it could become more desirable.


I think that the need to have a self contained personal computer application data program cannot be understated. It would need to have protocols for sharing data, it could start off with the simplest of features that are most wanted and grow. If the “Open Source Projects” stopped being productive you would still have your personal investment. Hopefully the code and structure could be modified by the (admittedly rare) user. IMO… You must be able to import YOUR data into YOUR modeling programs on YOUR computer so if the lights go out... if only for a moment, or the Open Source Group disolves (FY!! no FY!! WTF...) , or Mother Earth News decides that the on-line garden planning software business is losing money... you have harvested what you could and now own some portion of the program, the platform and the data.

We are going into hard times. Local food resiliance is very important though most people don't really know it yet. When they do show up to the party they will need help right away. Permaculture is essential. A method to get basic information that first year will be priceless. Building a comprehensive method of sharing bioregion specific information on essential nutrition can be delivered many ways. Neighbor to Neighbor, books, videos or a Simple garden program. Or a fancy modeling design...

I truly believe we must dream big, design practically, use available tools and resources, create trusted resilient communities, build modularly, Obtain a yield.

Namaste

Julie, You say you have a schema. Can you share it? Just the tables and fields and relationship woudl be great. Is it conceptual (in a ERD) or built? If built, what database product is it in?

Mike

I agree with what you’re saying mike

You repeatedly stress the need for native applications vs cloud. Is this primarily to continue development away from the internet (availability/future problems)? I’m all for that – there must be some mechanism to dump data however I would also argue that a higher priority must be the communicative nature of the program – phrased another way, without the community input this won’t work as well. Both are separate issues and not mutually exclusive, its just a comment regarding priority in building the structure.
“Local food resiliency is very important” couldn’t agree more. It will be a bigger issue as our national status changes. Already close to 30% of our food is imported… that means big problems in a currency disruption. It’s OT but a video was recently posted of Kyle Bass (hedge fund manager) giving a recent talk about the world financial state – incredibly interesting and troubling!

What do you see as the road map/steps to get this moving forward?

> saved to and runs on local PC

Ditto Mike. +++

The case for big picture planning and utilizing existing assets and resources:

There presently exists a time tested system with similar goals but relating to much broader and more general knowledge: The library system. It would seem worthwhile to keep this in mind and look closely at our library practices and methods because reinventing the wheel can get expensive, boring and disappointing. We usually go farther faster mo'betta by leveraging current assets. Maybe it's hard to see the connection because

1) The infrastructure of the library system has until recently been mostly wetware - human beings - and we're talking IT here.
2) The library might be seen as stodgy, "not with it", not tied in with permie needs, not going our direction, not sporting much new tech..
3) The library is secular - ie. it's very general, non-aligned. You can find how to make bombs as well as treat bullet wounds and be a mid-wife.

BUT this system has survived and proved it's benefit to our past and present culture and this is something we would like a permie system to do, right? _Any_ system functions and survives only w/in the context of culture/society/community/village - whatever you call the pile of humanity creating, using and paying for it. The permie-plant-info-base won't establish any meaningful relevancy, might not even survive, no matter what technical wonders and marvelous design it embodies, unless it becomes an integral part of a PRESENTLY EXISTING society and culture. Since the library system is a living and somewhat successful example of where the permie system wants to be (for it's own people), it seems like a good thing to examine very very closely. Especially as to how is fits into the community and gets used and supported - and why.

IOW, IMHO, if the permie system is to become more than a small elaborate technical demonstration toy it needs to make a deep bow and commitment toward its "customer base". Start from a need and work to a solution rather than create a solution and then try to connect with a need. Specifically this means addressing some questions:

a) Who will use the system? What do they want? What do they need?
b) How will they communicate with the system (call the local librarian?; dial up the internet? get their grandchild to figure out how to sign onto the system?; type in special commands? menus? microphone? print something out to take elsewhere so they can actually use it?)
c) How will the hoped for benefits be delivered to them (air mail? computer screen? audio? video? live internet? printer?
d) What will the system require of the user? (electricity?; internet connection(ever?)?; money?; English language?; typing?; spreadsheet facility? knowing plant taxonomy? hours of time each day?)

In my experience the above human component is what matters, almost totally. From a very narrow technical standpoint the above questions shout USER INTERFACE. In my experience designing computer reports and online entry screens in the 80's - and then trying to explain them to the people expected to use them - this is a non-trivial job that usually gets neglected or cobbled together. After which the only people who use the new system are those that cannot find any way at to to avoid it.

But also there is the question of how the system as a whole is presented and delivers to the community. How (assuming it does) it supports the community, why they support it. Admittedly the best laid plans always go sideways and at some point you just have to "do it". But doing some thought work, shamelessly examining other similar efforts so to have some moderately reasonable idea of what is needed and how you're going to deliver it should _really_ improves all the odds.

IOW. The backend technical stuff is doable but it won't fly w/out very good interface design (in the broadest sense) and that will all be wasted w/out introducing, teaching and promulgating it amoung the broad user base. It needs to be supported and accepted.

When I was designing systems they taught that you start by knowing the existing system fully and in depth. Then you find places where you _think_ you want to change (or add) things and you make a likely plan. Then you talk with the "victims" (users/customers - believe me they often have reason for paranoia) of your genius and see how you can modify your grand plans to avoid mass suicide or jihad. Then you... do it again a couple times to get it at least somewhat right. Then you try to make it happen. Oh, and the "system" is the corporation, the club, the company, the society, the department, the government... I do not refer to a strictly computer system. The system is a box you draw to give you a way to understand the people and processes you're trying to change/improve. In this case probably the rising (hopefully) permies culture and people.

Rufus

Hi David,

First let me say I am sorry for the delay. There are some bugs that have kept me from posting. My first brainstorm was eaten by the webdog.

I am not suggesting moving away from the internet or internet applications. I am just suggesting that from a users perspective the information that is MOST golden is what is in my garden and I must be able to safeguard it and use it when this years Open Source project falls apart (FU!!! No FU!! WTF @(^&(_$&) It happens. There can be a chain of inter-cooperative application layers using different technologies and alternatives. Each layer will probably have its’ own data input form. But there will probably also be other information harvesting techniques including API’s and simple Upload/Download formats.

I have been exploring the www.PracticalPlants.org forum and they are discussing the sourcing, consolidating and refining data from other Wiki style websites.
http://practicalplants.org/community/discussion/comment/43/#Comment_43

One comment I read on the site was that since it is a global data store, queries like... since questions like “what can I plant between May and June?” are only relevant to each biozone, they understandably do not contain that data. They are talking in depth about data and ownership and apparently get much of their data from PFAF. They also discuss the plethora of Wiki sites sharing, consuming and repackaging the same data.

My expertise is the creation of Client Server applications using MS Access and SQL Server. These tools are built to simultaneously connect to many data sources from SQL in the cloud, well formed XML documents, Excel files, Text files and your local database of “PLANTS IN MY GARDEN, FOOD FOREST or FARM”.

As an independent Permie entrepreneur I shouldn't have to have anyone agree with my choice of tools and approach and adopt it. I can invest (waste) all the time I want.  There can be many solutions for this layer if we do agree that there should be a way to exchange information. Not only should I be able to download interesting stuff from the central DB, I should also be able to export data that I have found into the library Parking Lot. However if I do create a package that others find useful they will adopt to it. Others won’t.

The Central Library (using Rufus’ good analogy) will assuredly have its own information input form (Planting Tool) where people can log in and add or update plant profiles. Finding enough people to reenter data that is available elsewhere might be a tough sell. Starting with a good pre-consolidation like PracticalPlants.org might be a good place to harvest from. There could be others. I could also imagine that there would be protocols (API connections or simple delimited text files exported from “Mary’s Excel file she has been keeping for 8 years with a wealth of information”). The data would not necessarily be as complete as the Librarian would like or be in a fully validated XML document, but it’s a start. While some people would enter each plant from scratch, others could review and scrub submissions…perhaps faster.

There will be similar problems harvesting information off of Wikipedia style community collectives. This is admittedly outside of my area of expertise so things may have changed, but for the most part this type of data is largely unstructured. It is a great way for people to share information that others will read through and filter and select. Human brains are fantastic and hard to duplicate. However, that is what Information Technology is all about - finding the kernels of information from within unstructured information resources and relating them in a Structured way (Central Library). One of the key pieces of information on each VERY STRUCTURED database record should be reference links to other UNSTRUCTURED resources that will add more human information… as long as it is available.

The attached image is of an Access form that I threw together to manage my part of our local permaculture community tree purchase. I entered in all of the trees on the list and started researching them, harvesting information from the web. I soon got tired of copying and pasting plant names into a Google search, so I built a function that would allow me to double click a plant name and the search would open automatically. I would look for size, function, description and past into each STRUCTURED field. As a harvesting tool I can highlight and copy a data element, flip to my Access app and double click on the field and the paste happens. Crude, perhaps, but it satisfied my business goal. Which of these trees do I want, how much are they and how many can I afford this year? This is the information that is unnecessary in the cloud, but now I have a core of data that I can begin to build on. This year I plan to start working on normalizing relationships. It is one reason I am interested to see what Julies schema looks like.

I hope I have answered your question and generated some ideas for moving forward. I am thinking about creating a Client Application that can work alone to harvest and organize unstructured web information and hopefully share it locally and then globally.

What do you think?

Mike

Hi Rufus,

I agree with your analogy of the Library and "the" system being broader than the IT tools used to leverage it. We are not starting something. Groups have been working on gathering (harvesting) data from many sources and consolidating them in unstructured (or less than completely keyed and normalized) WiKi's for years. We are talking about creating the next level of further consolidating Plant data into a more structured database (using the Permaculture principles) that can be interacted with by Permies to refine and regionalize... even down to where do i buy seeds for My garden in My Town.

I am proposing that Web tools can be used for much of the larger level of harvesting but if there was a Client Based program that:

held Personally important information locally and allowed the user to harvest MOST easily from a structured central Permie Plant library, AND
harvest data that was not yet available via their own web searches with cut and paste,
they (with their client tools) can then offer (upload) their information to the collective.

Yes there would be problems with cleaning and duplicating and specific (though un-sexy) tools would be need to do this ... weeding...

As for User Interfaces... there has always been a stressful dynamic between Users (user is a four letter word) and Developers (why can't the geeks just listen to me???) in an environment that is so rapidly changing. There needs to be more tolerance on both sides. A simple non-sexy interface may be a good supportable approach. Eventually it will be superseded by something better.

I look at it like food and farmers. Normal consumers just want cheap and good looking... A farmer does his best to go organic but there is a blemish here and there and it takes longer so costs increase. At the end of all of their hard work the normal consumer turns up their nose. The same with software. We need a CSA style system. Community Supported Software. Keep the wheels turning. Support your local software developer, accept some blemishes and eat the damn squash for another week....

The key will be agreeing on a dewey decimal system. Crude but consistent. Slow and Steady wins the race.

Your thoughts?

Mike

While reading your overview about the end user harvesting data to create and save information about their own plot it occurred to me that the main mothership database (not sure "Library" is the best term to use for it but maybe...) will also need to do a lot of harvesting. Perhaps they can both use the same basic logic and procedures. Ie. the mothership would basically use (mostly) the _same_ software as the client and thus there is potentially a peer relationship between _all_ nodes which (again potentially) will result in a distributed database that can be very durable - less centralized or dependent single providers. Assuming of course that the basic routines (functions, whatever jargon is current) are good. The main DB is very similar to the local DB including core functions, just much larger. Not trivial to create, I know, but one possible advantage could be that the basic functions could be implemented on a tiny scale as local "clients". "Harvesting" features, exporting features, "reporting and display", analysis... All that added bit by bit modularly - provided the 1.0 version had enough value to people that they _used_ it and thus provided that base to build on.

Which segs straight to my usual thought about the "user". Start there, find what's needed (your example of tree management might turn into the "killer app") and provide it in some way simple enough that "the little lady can drive it easily with one finger on the wheel". Look at Paul's trials with the tools and methods of audio and video recording. Read his posts and then read between the lines. That is one huge classic case of user/customer techno disconnect. He has a pretty simple desire/need but despite being tech savvy and motivated he can't get the damn system to do what he _needs_ w/out prayer, human sacrifice, voodoo and smoke signals. That is the classic failure of the user/technology interface and exactly what one wants to try really hard to avoid if a new system is to catch the wave and surf - and not just wipe out.

Another gnawing thought (a strong one) is that this type of data harvesting and sharing with networked and distributed peers has been done before - probably many times - and it would be good to study and perhaps build on those existing examples. We're talking years, maybe tens of years jump start for the permie-db-network if that can be done.

Another thought would be to hit up Google for help and technology; they might be interested and the "only problem" would be getting squashed by goliath as it casually inhales... At least get an API from them or see what protocols they have to use their search engine directly. Put it in a module because other seach engines would likely require other protocols - in their own modules. From all I've read, screen scraping is a real bummer to maintain...

Last thought: The "account manager" for this project should probably pay attention from the very beginning to how intellectual property rules might apply.

Rufus

Hi Mike, sorry for the delay. Work deadlines and bugs with the forum have delayed this response much longer than I wanted! Per your request I’ve provided for you the most recent depiction of our schema in the attached pdf. It is a little bit out of date, but the changes are trivial. A little bit of background:

This schema was planned for a single, specific location part Central Florida, and is being expanded for Orange County, CA. For the time being, our intention is for the databases for each location to remain separate, but share a similar schema. This decision was based on discussions of permies in CFL about use of “general database” not being specialized enough for our very unique climate. As the application is developed we will reevaluate this design choice and determine if a different route of action is better suited.

Let me know if you have any questions.

Hi Rufus,

First on the issue of information Ownership...

I have been exploring the www.PracticalPlants.org forum and they are discussing the sourcing, consolidating and refining data from other Wiki style websites.
http://practicalplants.org/community/discussion/comment/43/#Comment_43

Practical Plants are being pioneers (in a sense) in large scale harvesting and consolidating Plant information including being sensitive to Proprietary Rights. It is like a farmer walking along the edge of a field gathering seed but having to wonder if Monsanto has a genetic patent. While there may be many other who are similar pioneers, it seems that they are coincidentally (divinely) presented to our attention at this time. I had never heard of them before. I am now glad I have. Juliet is looking for API's and connections between their Motherships. This is way beyond me. Wikis harvesting from Wikis... WOW. However I do see that each of them has also found limitations in trying to be Universal. They are gathering information about plants... not necessarily where or when each plant can be grown.

By watching and participating in the initial conversations between them I can perhaps influence their development by sharing my point of view. I am a Client Application builder with a garden that I want to track and have useful links with other databases that help me to improve my selection of plants and reduce my personal research time so I have more planning and planting time. This is a very broad user requirement and will hopefully refine itself as we move forward.

I will trust them to solve the problems that will arise at their level. I will listen to the users at my level (local permie buds) and work on a parallel development focusing on MY plants in MY garden and hope we meet in the middle. There will be adjustments to make. Space ships have navigational thrusters that will be used to fine tune and adjust docking. So must our API's.

We will never develop a single DB schema or set of functions. We will never all think alike. We must agree on a handshake protocol that is flexible and adaptable. It would be great to have motherships use consistent APIs (Application Program Interface) but these are very technical and RIGID. Most commercial companies have created industry wide XML document standards to minimize these issues. I think that this would be the best place to start.

Juliet, are you considering XML document standards for information sharing? Is PP?

I like your Plant Schema but can see some missing dimensions that I would think would be important to a Permie. For example Plant Associations. You have an Insects that attract, repeal and intolerant. I would expect you to have a similar Plant to Plant (polyculture) structure.

Also I could not find an indicator of Annual or Perennial. I do understand that this can be effected by Climate Zone. Some Perennials must be replanted in colder regions.

There are other elements that are important to me but out of scope for you. My Micro-Bio-Zone information (Latitude (length of daylight), Average and Latest first frost/freeze and Last Frost/Freeze, etc.

And activity calendar. When to plant (Last Frost/Freeze, soil temp, hours of daylight) days until harvest (perennials= bloom to harvest, annuals = seed to harvest) These could be roughly derived by a combination of plant needs (frost free date and Local Micro-Bio-zone). These are the areas I am going to explore from the My Garden point of view.

In sharing information with other systems, how are you going to solve the problem of system specific relational keys. Many of the connections in your schema (ObjectID, PlantID_ptr, etc.) are the core of your normalization. They will likely be completely different than those used by Practical Plants. This will be a major problem in sharing data? What is your approach?

Any other thoughts?

Mike

I like fields with predefined values be they ranges or lists of text values, although some people have trouble with that stricture. It appears the J-schema <g> uses largely set value tables. Which I assume will grow dynamically. There is definitely need for free-text values (eg. Notes, or Comments), though as a WAG, I'd say only one per plant. Data which continually turns of in the free text field is begging for it's own table.

On a general note, it may be important to reference the source of data and/or it's reliability. When I keep my own info many times I don't qualify it because I have a good handle on how I got it and what I consider it's reliability. However, when "harvesting" data using automated processes or the work of other "researchers" we start to need a handle on how much credibility the info has. The medical records people have started to try to do this with their diagnostic algorithms and patient records. I think ("don't quote me" cuz I scanned this stuff on the fly while researching other things) each datum has a meta-data field ranging from 1 to 3, 1 being most reliable, and each value has a very specific definition to try to make it less arbitrary whether it s/b 1,2 or 3. This to help make it more useful in sharing the same info between different medical cultures, companies and countries. It appeared a rather interesting effort to quantify stuff that does not on the face of it lend itself to numeric valuation and it also appeared quite complex and somewhat of a royal kludge, but the application is in it's infancy. I mention it as an example of a culture that is trying to share info (actually, really Really NEEDS to share info) and seems to feel strongly that meta data on source and reliability is worth some serious effort. I think they're right.

Rufus

Rufus, i like the direction you're thinking in ( i think it was you in an earlier post)
if you think about the first days of the internet, yahoo vs google. Yahoo wanted to catalog every webpage but google said we can easily see important webpages by looking at how they are linked/network together. a library vs a community.

In this case maybe there is a way to start loging what people are planting where and with what which will show the successful "linking" in the network. Anyone can collect data on plants. Just data on plants is easy - information is easy but what we really want is the community of grows sharing what they do. Sharing experiences which will benefit everyone. We want to capitalize on the community of experience to build a network of growing paterns.

Dave

I'm not sure you referenced the right guy, but that's OK - I think what you're saying is when folks get involved and the organized data pile starts to grow that's when permies start to get a really useful "thing". My take is that the "right" interface that's accessible, convenient and provides some kind of value people need now will grease the wheels. Maybe it should have something like (well, somewhat like) Paul's apple icon - community value isn't necessarily just in the data.

One place to look for examples of involvement like that is the open source community surrounding Linux. Look and wonder how it hangs together, maybe... But it does and it's an example of _many_ people contributing millions of hours of extremely valuable work. Logging the story of a garden isn't the same kind of commitment but it _does_ require some effort and needs to give some kind of good fuzzies and other bennies so people can see it as a plus in their life. Damned if I know what all those programmers get out of their efforts but maybe somebody smart can take a look and see what open source does that makes so many people jump on, dive in and pound away for years. God bless'm they have made it possible for Joe Schmoe to compute with the big boys in many important ways! And that's kinda what (I think) Juliet and Mike have been talking about starting in the permies community.


Cheers, Rufus

Dan Pink actaully writes a really interesting book on what drives people - the prime example is of wikipedia. Why do people work their day job and then devote large amounts of time to something else, just as technical, for no pay. He says there are 3 reasons: Autonomy, Mastery & Purpose.
Those are the same things that i want to see in the development of this tool.

I think the tool will have value because of the combined wisdom and experience. More specifically, i think we can capitalize on the combined wisdom by building a network of links to show the validity of specific aspects of a design based on the number of sucessful links.
At a very high level, we don't need to take the yahoo approach and log every plant that could influence the garden. As we enter designs with greater and greater detail, the paterns of sucess will show what works together and what does. This information will make planting future gardens increasingly more and more effiecent. Instead of passing on info from generation to generation, we can speed on the process and save it for everyone, by sharing info on a new platform.
Does this concept make sense?

>makes sense

Does to me. I was just going to post about wikipedia but you beat me to it. <g> I'll see if I can find some of Dan Pink's stuff.

To reiterate my favorite mantra: The "project" needs to be dirt simple to start into and use and benefit from (from the individual's POV) and their "easy-like-pie" usage needs to render value and resources back into the project network sufficient for growth. I'd think that these criteria would go a long way to defining "phase 1" scope, interface and deliverables. The backend or insides of the black box I have much less to say about - I've been away from databases and coding for a _long_ time. <g>

Cheers

Rufus

I'm no help in implementation but wanted to support the vision by offering some mare ecological challenges:
#Information about a plant from a particular source, in a particular situation is an observation. Our knowledge of a plant is a composite of these different data points. No single source of plant information is reliable in all settings.
#Information about the context in which a plant occurs in its native range, within its community provides a VERY valuable insight into what kind of critter it is, and may not be applicable in a new climate/assemblage.
#Information about the range of settings in which a plant will bear reliably is more useful then survival.
#Stress tolerance will vary between climate settings. A plant that is drought tolerant on the East coast may not be drought tolerant in Nevada.
#Planting templates can be versatile when organized into canopy strata. Much of the design postulate is defined in how you envision 2-4 species to share space over time. This postulate is important information.
#Planting density is a function of how quickly you want your vegetation to dominate a site, and whether you consider the individual to be temporary or long-term member of a community.
#A lot of planting detail can be captured in percentage cover templates... yet this requires some definition of what the 'spacing' for a species (or even a stock type), which is defined by your purpose for spacing.
#80% of the inputs-outputs-intrinsic behaviors of plants are common to all plants.
#Selection of variety for local disease resistance can be very important.
#Grafted plant performance may vary dramatically based on rootstock attributes[/list]

Good luck...

I've been meaning to drop in on this thread ever since Juliet brought my attention to it. I'm the principal developer behind Practical Plants, and over there we're working hard on building a globally relevant plant use database.

The most important thing we learned is building a database like this is hard. Technologically it's easy... designing a database schema and thinking about what terms and properties you want to define in an abstract sense is both easy and fun. Once you start actually having to collect and build data, it gets difficult. It's hard to find reliable sources of data; it's super hard to merge that diverse data well; and it's harder still to build and maintain an active community to look after that data.

The difficulty in maintaining a community effort to build this kind of resource is one of the key points for me. The permaculture community is a passionate one, but it's not huge, and I don't believe it has the resources to maintain multiple databases without harming the effectiveness of each. Most of the work on Practical Plants is really being done by a very small number of committed individuals, with a large number of others making very occasional corrections. I'd urge any new database project with similar aims to Practical Plants to define how it might differ, and to open a dialogue with us - we're a totally open community, and very open to new ideas of what data we should define, how we should collect and share it, and so on!

We're really actively developing things further right now, and we've got some big changes in the pipeline. It's a great time to get involved and help steer and established database in new positive directions; then we all, as a community, are building a database we can use for any other projects we want to create... Right now we're working on:

- Moving to a server farm backed by major university funds, to guarantee we stay online without bills for the forseeable future
- Removing the Non-Commercial license restriction (the NC isn't as "nice" as it sounds, and can actually non profit organisations from using the data if they operate commercially in any way)
- Integrating new data sources from the biodiversity community for species distribution maps
- Importing established ontology terms to provide a more compatible API endpoint, and working on defining a plant use ontology for others to use (we haven't found an established one yet!)
- Integrating external data sources for plant pest information and plant interactions
- Experimenting with new methods of storing multi-factual data
- Data dumps in XML, CSV and JSON
- Improved API documentation

I would personally love to see Practical Plants working as a source of data powering applications which empower the permaculture community - applications which help people plan, design and maintain their eco systems. We're working on ways to export our data into a number of formats to power just this kind of thing. But it would make me really sad to see the data moved to a system which modified the data (sharing modifications between databases one they fork is SUPER hard), and we end up with two databases trying to achieve the same goal, dividing the community between them.

I think the most important thing in a community of this size is that we're all talking. There's not many people here with both the time and capability to build something like this, so our resources are precious. Duplication should be avoided at all costs. I invite you to join us at Practical Plants if you think there's an aspect we can improve, or failing that create a database which just covers areas we miss, and perhaps we can just display a read-only representation of each others data for everything else. I'd be really interested to see a list of ways in which your proposed database differs from Practical Plants, and to discuss if that's something we can work together to improve, or to discuss how best to minimise duplication of efforts if it's not something we can integrate.


Now, all that said, I am a dreamer. I look forward to a day when something like Practical Plants can be part of a network of distributed atomised databases which can share their modifications easily between them, much like a distributed version control system like GIT. In that future Practical Plants might just be a composite of numerous atomised databases (plant uses, plant interactions, biodiversity distribution data, pest data, and so on) and any other website can use the same data and allow modifications which are shared throughout the network. Where the data can be used offline and changes can be synchronized when online. A system to support something like that doesn't exist yet, but there ARE people working on systems to support those ideas. In the meantime I'm working hard on incremental improvements to Practical Plants, to build a data-source now which can be even more awesome in that kind of a future

Hey folks,
Any progress on the work described here?
I have some ideas after attending Permaculture Voices and would like to guild where possible.
Best,
John Ackley

Hi John,

As you can see we had a flurry of activity about this time last year and then I suspect that everyone got busy outside like I did. However over the winter I went on a developing binge and am close to releasing a client product to help manage the cycles of building and maintaining a perennial food forest.

Several people had been concentrating on the "Mother Ship" of plant data. Andru Vallance with Practical Plants made a compelling argument that we need to find a way to cooperate in building and maintaining a central repository for plant data. He makes the point that as soon a new project takes the core data into a new direction it is subject to fragmentation. There are several internet plant databases out there but many if not most started with data provided by a group in England called Plants for a Future (PFAF.org). Many have spawned new User Interfaces and dimensions of data that is now adding value in new ways.

These websites provide a great service to the world by collecting, organizing and presenting the data via websites with some powerful searches. "What nitrogen fixing plants will work in my Climate Zone?". They have a very big problem because they are collecting data on plants from all over the world that have adapted to different climates and conditions. It is the users (from every part of the world) who must sift through those plants (7,000+ at PFAF.org) to find the 1-200 most useful to them and their climate and growing conditions.

I, on the other hand have taken a different approach. I am supporting the Permaculturists who are BUILDING and MANAGING perennial food forests and gardens. My system supports 5 continuous phases in the PLANT portion of a project. To do this I felt that it was VERY IMPORTANT that the information pertaining to the plants in your project be stored on a client computer in case Internet access is no longer available. Therefore I have built a client database application that sits on the edge of the Cloud (internet) facing out and in. All of my forms pertaining to Plants, Planting Locations and Vendors have internal web browsers that act as "Favorites" for each plant, location and vendor.

When you surf and find something you like about a plant, planting technique, canning instructions or recipes... you just save the reference for the plant. To start the user off I have built in programmatic access to some of the most common internet search engines: Google, Bing, Wikipedia, USDA, Plants for a Future, Practical Plants (though I am having some problems with this one). You will also be able to add your own web resources and choose a default. As you walk down through plant lists as each plant is selected you can choose to do a default web search. I will often use PFAF or USDA (for native forestry species).

The supported project phases are:

Research – Explore plants, create and refine lists to create Your project plant lists.

Planning – define planting locations for up to four (optional) levels (Project, Area, Forest/Garden, Bed (Hagarville Food Forest, back yard, Food Forest zone 1, North Flower Bed)

Acquisition - Match the plants you have selected and find vendors. Create order lists by vendor, plant and/or planting location.

Management – create maintenance plans for each tree/perennial/annual (Year 1 Tree: prep hole, plant, compost mulch, prune, paint trunk, etc.)

Observation – Use the built in Garden Journal to record observations, when you planted, harvested, etc.. The journal also coordinates each day with Photographs taken of the project. I can take my smartphone (or digital camera) out into the garden periodically and tak pictures of each zone, tree, bush, bed or plant of interest. Later each Photo can go through a “Review” process where you associate the photo with any of the Plants (from your list) or Planting Locations. Then when you review plants (or locations) you can see the photos associated with them over time. June, July, August or Year 1, 2 or 3. The final observational component is that I use a $100 Weather Station that collects weather data and streams it out to the Journal. So for every day you can see the Weather (Hi/Low Heat, Wind, Rain, Humidity and Daylight, based on latitude), your journal entries, management activities and photos.

One of the best aspects of the system is that it keeps a history on where you get your plant data. As you navigate through the premium plant websites on the planet you also provide them page clicks for their advertisers and drive more new users to their sites.

Not only is the data on individual plants useful, but researchers (global, national, regional and local) also put together lists of those plants that fill a niche for their area. These lists may come from you neighbor or a favorite book from Toby Hemenway, Eric Toensmeier or a local website (www.SpokanePermaculture.org). Each Plant contains a web link to the source of the data and each “List” can also have a link to the website, page or book of the originator.

Enough about my progress for now…

How are you trying to plug in John? What in the Permaculture Voices conference inspired you to reach out to the IT space?

Also… are any of the IT bears beginning to awaken? Anything new happening with Master Databases? Anything else?

Best wishes to all,
Mike

Mike,

I was trawling around here a year ago looking for PC design software, bookmarked it,
and decided to poke the ghosts after returning from PV1. Thanks for responding.

That sounds like a nice chunk of work.
I especially like your effort to maintain the original source of information - a detail many overlook.
You are also right about needing to operate without internet - local storage is very important.

Everything from Permaculture Voices (One) is still percolating around in my noggin.
I was really blown away by Elaine Ingham (soil life), Allan Savory (systems thinking),
Craig Sponholz (waterway restoration and hydrology), Joel Salatin (alternate business models),
and Jack Spirko (PC *is* a business model). But all the other speakers were awesome, too.
Paul Wheaton was absolutely on fire - I thought he was going to spontaneously combust on stage - must be that rocket stove in his overalls.

My background is systems engineering and software dev.
I want to tackle the initial land survey, mapping and design part, since that is the part I personally need most right now.
I especially am interested in novel mechanisms for entering/capturing map/contour info in the field.
Not happy with existing solutions which (even though some are free) are a high barrier to entry for tablet/phone users
and offer very little, if any, integration to down stream design and analysis processes.
I want my data to talk to my other data without having to always be resident in my frontal lobe.

I will need plant placement and coverage, too. Your selection and ongoing data collection sounds good.
Would be happy to use yours if available as a library/plug-in/something.
I want to move quickly, but also want to have modular architecture to permit optional/third-party plug-ins
so we can more easily collaborate and allow mixed open-source/commercial code (kind of like Eclipse).

I ran into half-dozen or so other software developers at PV1.
Several seemed hot to do something real soon and might be interested in broader collaboration.

Thanks and best regards,
John

Lots of the insight from this thread were used for inspiration in our new project: Permapeople.org

Some of us Permies have been building the next generation of plant database:
https://permies.com/t/153923/built-plant-database-open-permaculture