Fig variety database

[WillsC]

One thing we really need for our forum is a quality and accurate database of varieties. I'm looking for a person that would be willing to head up this important project and those that would like to be part of the committee that would bring this together. It will be a group effort and we would need submissions of pictures both of whole fruit, cut fruit and leaves.

If you are willing to be a member of this project please PM me.

Wills

[AscPete]

Wills,

Thanks for starting this project. I think that its important at least for the currently available cultivars in circulation....
I would be happy to help as part of the committee...

[Hershell]

Wills, I told you that Pete would be good at this, and look who volunteered.

[AscPete]

Hershell,
I've already started my personal "documentation and database". Its simple to email or post a few pictures.
Just look at my avatar, right now its a Conadria EL, showing typical mature 5 lobed leaf and a ripe fig. ; )
And if you look in my Profile... Media, you will see pictures of a few other cultivars, all taken with a Cell Phone... It doesn't have to be complicated.

[newnandawg]

Hershell, I believe you to be a trouble maker my friend. LOL

[aphahn]

I'm currently building a site for the North American Scion Exchange that will have a variety database of fruit, nuts, etc, and including figs of course. It will be a community built searchable DB with the ability to add, edit, comment, describe and add pictures of varieties. Everything that gets added can be ranked by the community as accurate or not and curated by those who are passionate about it.
The varieties DB portion of the site will go live in a couple months (depending on how fast I can code).

Does that sound like something that would be of interest to this group?

[zone5figger]

Great project, Andy!

[MichaelTucson]

kudos...

[greenfig]

Andy, absolutely!
I wanted to propose exactly the same but you beat me to that
The question I still have though , will California be excluded again? I think the answer is yes ...

Like on eBay, no shipping to HI and CA

[aphahn]

Hi Igor,
Anybody can join, and where NASE members ship to is at their discretion (though they are strongly encouraged to follow all applicable regulations). There are currently lots of members from CA.

To be clear though, my intention is not to recruit more people to the NASE, but to see if the platform I'm building for a variety database would be of interest to Wills et al for the fig database.

[eboone]

Andy, are you suggesting separate databases using same platform or that this forum contribute to the NASE database you are building?

I like the idea of members being able to add leaf photos or comments regarding a variety's ripening time or quality at his locale. As valuable a resource as the F4F varieties listing is, it has become stagnant from lack of updates and info only from (generally) a single grower and location.

[aphahn]

Good question Ed!
I'll be honest, my preference would be to have only one database, and the NASE seems like a great place for it to me. However, I am open to discussion. I will be open sourcing the code (GPL) so there are lots of options. From a standalone DB, to some sort of integration, to both communities sharing the one resource. Obviously anything that would require more code would take longer, but I don't think that holds up anything Pete was talking about.

[MichaelTucson]

I support the idea of one database rather than two, particularly if the communities of editors& contributors overlaps to any significant degree between the two communities in question. (This also depends on whether you envision similar "contributor entry criteria" among the two communities). But maybe my "vote" about that shouldn't count much, as I'm not volunteering to help set it up. Just advice from a tangentially-interested party. Tangential interest: I would be interested to contribute some content if that suits your sensibilities... but that is of course a far different thing from the project of designing and establishing the database system. Good luck, and kudos to those of you who take this project on.

[MichaelTucson]

Ed: Good comment about vibrancy. I'm amazed at how much effort Jon must have put into his F4F varieties pages. But I agree about the stagnation problem. One guy can do only so much. I was going to post a similar thought to yours, but found you had already hit the nail on the head.

Still, this problem of "who can contribute" and "who can edit" (potentially two different roles) is interesting. A single editor/contributor leads to some problems, but "too much openness" can lead to the wild west. (Willy nilly, as some on here have said). That's where separating "contributor" from "editor" roles may be helpful. Being pretty open on "contributors" (someone who can add something, but cannot remove or change what others have contributed) would help keep it vibrant, and provide plenty of sources of info. But a bit more restrictive on "editors" (a smaller set of invited/trusted persons who have broader powers to make corrections to anything) helps avoid the wild west problem. Some systems have multiple levels of "editors"... i.e. a set of editors with limited edit capability (think content but not structure), and one or more "supereditors/administrators" who can change almost anything.

Still, this whole arrangement leaves a sizable burden on the "editors". They have to be active. They have to be knowledgeable, yet open to learning and to changing their own preconceived notions. Lots of these attempts fail because "editor" requires too much effort/seriousness/openmindedness/balance, and when there isn't enough effort applied by editors (or super-editors), the discipline and the database value break down. So the trick seems to be finding appropriate entry criteria for the people in each layer of the community. Open enough that it remains vibrant, but something to deal with the "wild west" problem introduced by rogue contributors. Also, the community has to be big enough. And probably have an appropriate level of turnover (or new joiners). Some communities turn out to be self-correcting despite being very wide open. (Witness wikipedia). The problem is, no matter how much "self correction" is applied by disciplined participants, if it's too wide open then AT ANY POINT IN TIME it may contain wildly inaccurate junk. One troll can do a lot of damage in a short time. Also, too small a community can give false confidence or project a false sense of accuracy: Consensus among a couple of hundred people hardly ensures that they got it right... history abounds with examples where the many overruled the few, and "got it wrong" in the process. Further, too often a lack of objection is mis-perceived as a consensus. Consensus requires active engagement by a community. But an assertion that is voiced by one and backed by two more people, and has no voiced objections from a wider community of 200... that is still just the opinion of three people, not a consensus among 200.

OK, enough about this! I guess I'm interested in this problem. But not enough to take on the task of doing the setup. I really did just start out here intending to support your comment. You hit it right on, Ed.

[MichaelTucson]

If you guys want the database of fig info to be member editable/contributable (and community-correcting), then please at the outset pay some attention to format and structure. There is a lot written about community parameters and strategies that lead to successful self-sustaining wikis. If you really want to take this task on, I'd suggest that it's worth the time to be thoughtful about the format and structure, and "rules" (the update parameters), as well as the template to use.

Mike

[aphahn]

Do you have any resources to suggest that would help with that process Mike?

[MichaelTucson]

Nope. Sorry Andy, I don't any specific articles at my fingertips. But I've seen enough examples of similar db attempts eventually fail, that it made me want to suggest that it's worth investing up-front effort. I do recall one article from IBM Research (published back in the early 90's I think, and I think it was from the T.J. Watson research facility, rather than their center in France or on the west coast) that provided a graphical representation of the way that a wiki community self-corrected. (It may have predated use of the term "wiki"). It also had suggestions about the nature of the community, and gave a few examples. I think it was discussing "closed communities" with at least some joining criteria rather than purely public communities. But I can't find any reference for the article. I do believe though, that with the popularity of wikipedia and other wiki databases, the problem of defining a few simple rules for allowing edit authority has probably been studied and written about. Outside of wiki rules (particularly who can edit), I think there is quite a lot of literature about database design principles in general, especially relational databases. It's a career path specialization among computer scientists and information technology people. Professional librarians have contributed a great deal of knowledge as well. But I'm sorry, I can't really offer anything concrete to help you. Plenty of abstract though :-). I'll close with a paraphrasing (and slight distortion) of a thought from Albert Einstein: keep it as simple as possible, but no simpler.

Good luck in your project.

[aphahn]

Thanks Mike! I was hoping you would have some insight, I have not found a ton of useful info about "wiki theory".

[Kelby]

I PM'd Wills already, but I'd be happy to contribute as well. At least pictures and any info I can help research. I offer up my hardy fig spreadsheet if that is at all helpful.

[WillsC]

Thank you all for your thoughts. What we really need is a project manager for this who would have database experience.

[MichaelTucson]

Exactly. It's a sizable undertaking, for volunteer work.

You won't have any shortage of volunteers to be contributors.
And if it's a separate role, you'll probably have volunteers to be editors (maybe even some of whom will remain active and industrious in the effort).
Having a project leader to spearhead the whole thing... that's a harder thing to find a volunteer both qualified and willing.

[Kelby]

Thank you all for your thoughts. What we really need is a project manager for this who would have database experience.

I'm not going to pretend to know a thing about databases, but could creating some sort of spreadsheet work? Wouldn't be too fancy, but if done from a Google Drive (use the Sheets app) account it can be set up to have various accesses. Some people could edit and anyone could view. It could work at least for a start, it would also standardize whatever information you would want to list, a column for whatever info is wanted. I use Google Sheets and like it, I haven't played too much with adding photos, but it shouldn't be too hard.

[Kelby]

Just did a little reading, a linked photobucket account could be used to host and link photos into a Google document. Not too hard, but it might be more steps than needed.

[Kelby]

https://docs.google.com/spreadsheets/d/1JS9UmaBE15NJi7Xa8v8brsofB3bM305L-MuqX7q2o3s/edit?usp=sharing

Here's a demo of what could be done in sheets. I'll stop now unless anyone wants to see more.

Mike (newnandawg) - I linked to one of your photos, hope you don't mind.

[Chrisk]

Awesome idea. I will definitely be contributing. We can start by posting a topic on a variety at a time. Everyone could then post photos of that variety but only dy their own growing experience. Try to include a group of leaf ,embrios and ripe fruit if possible . Then we can choose and catalog it all. NOT pics from the Internet.

[Snaglpus]

If you want to do this database right. I recommend making it normalized. IT folks like me can relate to what I am saying here. And it should also reference (as a source) Accession Ids at UCD. It should also reference all of the fig names and pictures listed in Jon's website even though some folks don't agree with the naming of figs. Why? Because UCD and JV have existing data and pictures that link back to other sources of figs that were donated to them.

Everybody loves spreadsheets and they have a specific purpose if you utilize the true power behind spreadsheets. BUT you can't query a spreadsheet, you can only do that with a good front end database application tool. Just my 2 cents......

[MichaelTucson]

I agree that this calls for something other than a spreadsheet. For the reasons you stated, and plenty of additional ones too. (btw, I don't agree that EVERYBODY loves spreadsheets... take me for example :-)

[joann1536]

I'm not specifically an IT type, but as an engineer, I have used plenty of both spreadsheets and databases. I completely agree. A spreadsheet is a marvelous tool, no disagreement there. I have one set up to track the progress of my own little collection of figs. But this particular task is better suited to a good database, containing all the above-mentioned references. Whether one agrees with the naming or not shouldn't affect whether the information is referenced.

[eboone]

Dennis, can you define 'normalized' for us non-IT folks?

[MichaelTucson]

Ed: (obviously I'm not Dennis, but) I think 'normalized' refers to having a structure that avoids internal conflicts and contradictions, mostly by using pointers and references to information rather than storing "the same" information (or information that should be the same) in two different places. If it's got multiple places to store the same info, then when they get out of synch, you've got garbage. At least, that's how I think about it, in laymans terms. There's undoubtedly a more succinct formal definition.

You can also think of it in terms of correctly identifying the relationships among different parts of the structure (different fields). I think that's the context here anyway... maybe Dennis will clarify what he meant.

[Bijan]

I built a database several years ago (about the time Jon started Figs4Fun). When I posted the idea, there was not a lot of interest. The most encouraging statement I got was from Gene Hosey who said something to the effect of "if you build it, I'm sure they will use it."

The database was composed of several parts:

• Static data on varieties. Giving basic information such as synonyms, color, pulp color, leaf shape, tree structure, etc. I had a pdf file from some group with a list of identifiers that I tried to incorporate. Also was the following information
  • Figs4Fun information - even though the most of the data Jon compiled was verified to the accuracy. I thought it wold be somewhat helpful
  • Hilgardia information
  • Condit's work
  • UCD information
• User data on varieties. This information could be grouped by location/zone
  • Characteristics of varieties. This information could be added annualy
  • Timing (breaking dormancy/fruiting/etc.) Added annually
  • Flavor profiles
  • Other data
• Tree tracking. This was the most important factor for me in the database. Each tree (including those in UCD, Pursch Park, Jon's, etc. orchards) would receive a unique serial number. As cuttings, air layers, etc. are passed along to other members, the parent trees' serial number goes along with them. As the cuttings become trees with a unique serial number of their own, the parent tree's serial number would be references. This would help with two problems. First, if a tree has been misidentified (or an unknown variety is identified) the family tree can be traced and the correct identity can be applied. Also, it would minimize the need for subsequent identifiers on variety names. BTW, for those of you who received a 'Celseste" variety tree labeled AA001 or BJS002 (AA002) those descendants of the first two trees I ever bought.
• Planning Tools:
  • For trees growing in the ground, the location of the trees could be identified
  • For trees growing in containers, the size of containers, when root work was/needs to be done, growing mix, scheduled uppotting, etc.
  • Propagation schedules (how many layers/cuttings expccted in 20XX)
• Wish lists: Including prioritization of wish list. This could be tied to other users' propagation schedule to facilitate fig migrations.
• Print plant labels: A variety of formats which could include data from above.
• Vendor lists. This could be a source of income to support the database expenses.

My original database is done in Filemaker 8 (They are now up to FM13). It was a very easy to work with relational database which at the time crossed the PC/Mac platform. It was also what was installed on my personal laptop by the company I worked with.

I agree with Dennis that a good front end database is important. The format the data is presented to the end users can be adapted depending on the depth of information desired.

[MichaelTucson]

Wow, Bijan. Was it you that put together the structure that is now presented in Jon's "varieties pages" on F4F?

Besides supporting your statement (and Dennis' statement) about this calling for "a good front end database", I'd like to add that the back end database matters too. The front end just defines how it'd be presented, but the back end (the structure for storing the data) is a part that requires some real thought and expertise. Sounds like that's what you tried to establish. Is it what eventually generated Jon's varieties pages? (If so, then whatever advice you'd offer to those taking on this endeavor, gleaned from that experience, what worked and what didn't, would likely be quite valuable).

[Bijan]

No,

I was not involved with Jon's pages. I was working on something different at the same time. At the time, I was about 30% done with what I wanted to do, and realized it was going to cost quite a bit of money to finish and maintain the database, licenses, website, etc., and I had a lack luster reception to the idea. So...

[Snaglpus]

Sorry for leaving you guys hanging. Let me see if I can break this down for the non-Techie folks. Data architecture and data quality is my daily job. I've worked in all industries from the large banks to tiny MS Access database working for Habitat for Humanity. And been doing this work for over 20 years.

Basically, a database is normalized when you have one fact about a piece of data in one place. Think of going to the AMT machine to extract some cash. You can take your AMT card and using only one pin number get cash, move cash or deposit cash. What gives you the abiity to do this is one fact that relates you to your pin number, your account number. That one fact, the pin number is only valid by you, your name, your account and your card number. You can't use your card and your pin to access any other account at the bank unless the bank authorizes or link your account information to another account like a saving or another checking account. If you could do this you would get wrong data and one pissed off person loosing money. Understand. In other words, if a person were allowed to access other people's account that would cause all sorts of data problems and violate all sorts of rules and privacy.

We have to normalize figs because there are so many different varieities of figs that have different data and different sources. For instance, UCD uses Acsencion numbers to identify figs and many of us request cuttings from them every year. It would be a shame to have a database of fig varieties and not keep exactly where that fig came from. Plus there are many different strains of the same variety of fig out there. So, if we have a normalized database that's designed right, we can incorporate things like Ascension number and any other data value at a later date.

A database is no good if one can't extract data or query it. This is where a front end application comes in. A front end is just a tool----aka an application like Google, Safari, Internet Explorer, OurFigs, Wells Fargo App, etc. Databases and front end apps should always be separate. In other words, don't use MS Aceess. MS Access is not scable and can not handle a lot of users and a lot of data. Trust me on this! I've spent a lot of years converting MS Access database applications that were created by computer programmers that don't have a clue about normalization and database. They just start throwing every piece of data into a spreadsheet of one table and think it can do every thing. Sorry, it can't! If you want, use free databases like MySQL or SqLite. These 2 are powerful enough to handle a fig database. But if it were me, I would not call it a fig database. I'd call it a Plant Database because many of us grow more than just figs and it would be nice to have a database designed once that can handle changes in the future.

For a front end, well, I'll leave that us to the computer programmers. But whatever they design, make the front end so that folks can toggle things like Region, plant zone, size, color, taste, open eye, etc. The choices are endless but design the database right the first time.

Hope this helps.

[eboone]

Thanks Dennis!

[joann1536]

Excellent analogy!

[SharonC]

Sounds like a very big job!

[Snaglpus]

Not really Sharon. The hardest part is the front end part. The database may only have 3 or 4 tables max.

[Harborseal]

Make sure you leave a large field for the DNA sequence and you have a QR generator for each type. Access is great for an individual collection but the master list will have more Celestes than most people have plants. It will be a lot of work to get all that data in

[Kelby]

I was wondering about that...is there going to be some kind of line drawn at what gets included? Do you include every seedling found in California and every bush found in New York City? Makes me wonder if there shouldn't be some sort of rating system for "A" type which are known varieties and "B" type which are unknown? That's just an example, but I think it gets the idea across. That's part of what is annoying to me about the f4f database... some seedlings have a paragraph and multiple pictures while Black Bethlehem (for example) has nothing.

[WillsC]

There will be a group of people that will make those calls.

[MichaelTucson]

@AscPete: Hi Pete. Not sure you intended this, but your "Fig Varieties Test" pages are publicly viewable. I saw them when not logged in (Abruzzi caught my eye), but as soon as I logged in I got the message that I'm not authorized. (Was going to post a "what rules/guidelines" question, so I logged in). Anyway, just wanted to alert you that if that's a test that's under construction, you may want to check your ACL settings... public can see them, but logged in cannot. (I'll be patient awaiting... just figured you meant to block public).

Edit: I mean the "Varieties Test" subforum. (with a Ficus Carica Varieties topic). May want to check your ACL just in case that's not as intended.

[AscPete]

Hi,
Thanks... Just testing an Idea... and no it was not intentional....

[MichaelTucson]

YW. I figured probably not.

[apnoist]

I support the idea of a correct new data base for figs very much! Some thoughts from my side....
Known names, synonyms, different names in different languages should be considered.
Phantasy names - something very common, could be marked as such, otherwise the number of new varieties will increase equivalent to the amount of collectors and/or increase exponentially with the number of (ebay) sellers. I can tell that many "new" varieties are not unknown varieties, but often just named by the finder, or even renamed.
Every fig lover, who grows trees from cuttings until they fruit, knows the feeling, when it turns out after years, that the "special one", is nothing but a common one.

[KK4DFU]

I would be happy to contribute to the database design. I work in clinical research informatics and my team designs software for data collection. We are pretty much hoping to do the same except with figs. I know of many open source tools that we could tie together to get this done.

Andy what technologies are you using to for the North American Scion Exchange?

I am familiar with oracle and java but am learning about mysql as well.

[aphahn]

The NASE is being developed in php as a set of extensions to phpBB backed by MySQL. The choice of platform was dictated by the need for cheep hosting. I would have preferred MEAN or other cutting edge stack, but there is something to be said for a very mature and secure project to use as a base.

If you are ok with learning php on the fly (that's what I'm doing), you are welcome to join us. vBulletin is php based as well.

Where do you work? I just left a clinical software project at McKesson last summer after 5 years.

[Whiterk]

Any headway on this? We are in the season now where people are harvesting and sampling figs. It would be good to capture some valuable information and continue to document the results we are having.

[AscPete]

Members are contributing to the Varieties List, http://www.ourfigs.com/forum/variety-test
and usually contribute their info in the requested format, http://www.ourfigs.com/forum/variety...before-posting , but all contributions are appreciated. http://www.ourfigs.com/forum/figs-ho...-list-subforum

Also photos and comments can easily be shared between the Open Forum and the Varieties List 'database'. Looking forward to your contributions to the database. Thanks.

[Whiterk]

Maybe update the list after this weekends LSU visit. We should be able to gather lots of info on the LSU varieties.