A new hot pepper database - with an emphasis on keeping track of names and varieties?

Pimental

Pimental

This is just an idea of mine - let me know what you think.
 
Pepper databases are cool, because there are so many varieties out there, and it's nice to have a way to keep track of them. It seems that there are a lot of different pepper lists and databases out there, but while they may have lots of info on individual plants, and even include rare varieties, none come even close to being unabridged. Now, I don't think that would be possible to have a "complete list" - there are far too many cultivars out there, and there will continue to be new ones. But I had an idea for a way to more comprehensively list the pepper varieties out there.
 
It seems like most databases on peppers out there try to have every bit of data possible: heat in SHUs, photos, growing tips, etc. Although these are useful, they take time to collect. I would like to, instead, make a database of pepper names. This may not sound like much, but it's one of the first things you need when you want to find info on a pepper - its name - and any other names/codes it goes by (alternate names, Its Christopher Phillips collection number, CGN number, etc.). The other two things I was thinking of including would be: minimal pod info (color, shape, size), and minimal genetic info (known related peppers, is it a named F1 hybrid (ex. super chili) or just a stable cultivar (ex. orange blob), and any known parentage). In this way, a relatively large database of peppers could be constructed, with minimal effort on a per-pepper basis.
 
The other aspect of this would be actually producing the database. I have some Access knowledge, and feel comfortable with learning a bit more SQL to get the job done with some SQL file-based system. One way I thought of, for filling out the database - at least as a start - would be to ask people to just enter the varieties they've grown themselves.
 
Any thoughts?
 
Best,
-'Pims'
 
I like it!  I know one of the companies I collab with uses tadatabase.io for some of their projects and efforts.  Don't think the pricing is "friendly" though.
 
I wonder if this could be a plugin/module/extension or something to this forum?  Wonder if @the-hot-pepper has any thoughts.
 
IMO, hosting it on this site would be difficult, at least initially. I'm no web developer. I could help put together the database a bit, but someone else would have to make the interface software, to make it user friendly, and searchable. Although even initially it'd be pretty usable via the software I mention below - it's super intuitive if you know excel and you don't have to know a bit of SQL or code, although it helps.
 
To be honest I wouldn't be able to do a whole lot of data entry, I'm pretty busy. What I was thinking was that I could give out a sample database that everyone could fill out (and edit with the free program from sqlitebrowser.org), or maybe even an excel spreadsheet for those who didn't feel comfortable with learning/using new software associated with databases, then I would import them into a database and keep it updated and posted on my website.
 
I already put together a SQLite database, but it has no sample data. Within a week I can put a few examples in. But again, unfortunately, I don't have the time to work extensively on this. If someone is home-bound rn, maybe they'd be able to put in more work.
 
Best,
-Pims
 
Edit: I did just spend some time putting together a database, but now I'm half wondering if it'd be easier to just make an edit-able google docs spreadsheet - which everyone will know how to use (And I'll put up instructions), and then afterwords, I'll download it, convert each sheet into a CSV file, and import them into a database - that would be a lot easier for everyone.
 
Why not use something in google docs or onedrive that everyone can have access to, but limit the edit permissions to where they can add but not modify existing entries. 
I might have a sharepoint guy who can give me some idea, but we're not a DBA by any means.
 
I've been thinking about making one. I'm a fullstack MERN (MongoDB, Express, React, Node) dev. The only hard part is all the data and getting permissions for images, lol. I've seen something on Google's APIs about pulling data from Google documents, but I've never tried it.
 
edit: yeah, looks like you can pull that data and display it on front end.
 
https://developers.google.com/docs/api
 
edit again:
 
Actually, Google sheets might be a better idea.
 
https://developers.google.com/sheets/api
 
I can do any development / hosting on the idea.
Juanitos makes enough to support hosting costs.
it is pretty dead i haven't made an update in 6 months, see activity page, but i am happy to work on it.
 
pepperdatabase.org
 
The problem is getting active users.
A database is pretty boring.
You either are searching for information or updating it.
 
people like to visit places where there are more active userbases.
thp, facebook, reddit, twitter, etc
 
---
 
next the biggest competitor in free information is wikipedia
it is not hard to create an account and create pages
but the reference citing requirements / image uploading is a pain
 
it is more for hard data by accredited sources not just gardeners growing stuff in their backyard.
(even if we are a primary source and have direct knowledge)
 
also reviews are not possible
 
---
 
so really the questions can be rephrased to:
 
how to get people active on a site they will only check maybe 10-20 times a year?
 
how to get people to spend time updating varieties they grow?
 
how to reduce barrier to entry. so people can post freely easily?
 
how to get people excited / interested about it? i currently do a terrible job promoting it.
 
---
plan 1
at first i though oh my website is crap maybe that is the problem. also i wanted experience using a new web framework so, why not.
i rewrote it using material design similar to a google application.
it is not perfect but it is more readable now
but that didn't bump any traffic
so i didn't have much motivation to work on bug fixes much.
 
plan 2
create a page for discussions. 
with active user engagement on the site maybe people would update the varieties they grew as they came to talk to other users on the site.
i tested this a little bit but without users this is kinda pointless.
most people already post on facebook/reddit/thp they don't want to post on this website as well.
 
plan 3 
i wanted to learn google single sign on. 
so i implemented it, maybe that would be easier for users than managing another password.
 
users still have to create an account so maybe that's still too annoying!?
but i want to track users. maybe eventually doing a ranking system and make users easily contactable / searchable
also the main reason to require accounts and verify email addresses is to stop spam bots from posting ads.
 
plan 4
add notification system so users are prompted to come back to the site if they are tagged or a post / var they follow is updated.
i tested this a little but with no users doesn't matter hehe
---
 
current plan
 
being an admin of the reddit seed exchange i have control of how it is run. currently we just used spreadsheets to record it.
 
my idea is to implement a whole database system for the exchange on pepperdatabase. 
users will upload their submission data (variety name, pictures, description, num packets, etc) 
 
did you notice that data!?
that's the same kind of stuff i am looking for on variety pages!
i can sideload all that information into the variety tables! 
wooo i tricked people into updating variety information for free.. lol
 
another benefit
we can run this like a real life seed bank! accession data!
but even better since we have a yearly exchange we can keep the data updated annually! 
 
this means someone grows a reaper strain 111 from joe bob, 
in 5 years if people continue to grow it we can see its expected phenotype, germination rate, etc. 
 
then when trading you can be sure you are getting the exact phenotypes you want (because they will all have pictures)
 
"oh i was browsing reaper accessions and i think i like #111 submitted by joe bob the best, i'm gonna message him or one of the others who grew it, or comment on that accessions page and tag someone"
 
or we can also identify bad phenotype accessions and also identify users if they are sending in crap seeds.
"90% of accessions sent in by billy bob resulted in bad pheno... maybe he needs help in his grow or.. i don't want any of his seeds"
 
With the data can also use it to collect statistics if we want to provide users with insightful information
50% of all jalapeno reviews report it having randomly varying heat depending on your source
90% of reaper accessions don't have tails. XD 
sandia pepper has 100% favorable reviews on all accessions, must be a great pepper
seeds sourced from juanito have been posted 100 times and 100% germination rate yay they are the best... lol
 
anyway this post is too long, feel free to comment on anything.
 
visit the website and let me know why you think it sucks, heh. 
 
https://pepperdatabase.org
 
sample pic
cYDk5RC.png
 
I don't think the site sucks. It's clean and modern but could be improved. I haven't used Vuejs in awhile, but the links are telling the server to send the entire website. That's how they traditionally work, but it should be a SPA. Did you use laravel on the backend?
 
Edit: I wouldn't mind helping out with stuff. Vuejs and laravel are not my tech stack, but I've used them on projects in the past. It's easy to think your website sucks, but it doesn't.
 
Suggestions:
 
Use vue router on links. It's probably similar to react and I know react-router-dom well.
 
If state gets large implement vuex for state management. I'm very familiar with flux pattern from redux, so reading over docs would allow me to implement and set this up if you wanted my help. It has been some time since I've used it.
 
Back buttons to go back to the previous page. The place that made me think this would be nice to have is when you click on the particular pepper variety and species. The back button could send the user back to the previous page in their history.
 
Improving text:
Where the text is a little dense I think increasing the line-height would look better. In some places increased padding bellow the images would look better.
 
Maybe cards are good in certain parts.
I think here is a good candidate for using a card:
 
https://pepperdatabase.org/variety/show/7-pot-barrackpore-red
 
The image could link to a larger one, which can be presented in a modal or the image in a new route with a back button / return button
 
 
edit again: I think implementing google Oauth is a great idea. I know how to do this with node and/ or Firebase. 
 
Dulac said:
I don't think the site sucks. It's clean and modern but could be improved. I haven't used Vuejs in awhile, but the links are telling the server to send the entire website. That's how they traditionally work, but it should be a SPA. Did you use laravel on the backend?
Click to expand...
 
it used to be php / apache.
but i have been use vuejs for other projects and wanted to convert this one as well.
but i didn't want to completely rewrite the whole backend application as a SPA.
 
so what i did was just use vuejs from a cdn, so each page essentially recreates the whole app.
not pretty but it is nice for retrofitting an existing application.
 
i don't use laravel
 
here is an example of the seed exchange page
QgGtVvV.png
 
IC. I've used vue instances on WP sites, just cause I can't stand working with WP on front end, lol. That's a nice feature of vuejs compared to React and Angular. I can understand not wanting to rewrite the backend. Rather than back buttons, you could use modals to reduce loading.
 
I didn't know about the pepper db project... It certainly is a welcome undertaking, at least for me.
 
My 2 ¢... If you want to get more people involved, you might want to conceive the db as a collection, and its users as collectors. Take as example the League of Comic Geeks website, where users can add all the comics they own(ed), read, ... to their collection. Translate comic collection to pepper grow list, where every grower adds the cultivars he is growing this year to his grow list. The grower can add data (from disease resistance to images), and if a particular cultivar is not available, he can create a new page (expand the db). Growers can make multiple grow lists, per annum for instance, so they can also access their information from last year, or even before.
 
Data base searchable… Hemerocallis http://www.daylilydatabase.org/search.php?advanced

The above is just on[SIZE=10.5pt]e way I've seen that I like of having a searchable database. Users can register via [/SIZE]https://daylilies.org/resources/daylily-registration/

Just food for thought.

The problem I see though with many names in the pepper community... we may have more than 1 Darth Maul pepper for instance and both are C. chinense hybrids.

So, we have hybridizers that are potentially naming their pepper the same as another person names their hybrid... perhaps because they aren't aware of the other hybrid with the same name.

Still other vendors will flat out tell you they are simply selling a renamed pepper... "This is just another jigsaw"' So, we have the problem of renaming or using an alias whether we are talking trademarked peppers or not.

Many times the heritage is not known as well. We have some hybridizers that rely on insects to do their pollination for them. Then they dutifully collect the seed... grow the seed... and hope for something new or interesting to pop up.

The problem with this is that you can't really track more than one parent that way. To be truthful, even if you hand pollinate you may make a mistake. Your cross potential contamination of your pollen source, stigma, etc. prior to your work. Many things come into play and with a self-pollinating plant sometimes we are dealing with a best guess even with those that are trying to do their best. Seed can even be mixed up in the planting and growing out stage so if your talking about an f1... things can be even more crazy. Don't get me started.

Show me the pudding, if there are no clear markers that one can look at to show the parentage... we simply have to say the hybrid is unproved on one parent's side.

Then we run into the very real problem of some people trademarking a name to sell a hybrid under. So, you might have a hybrid being sold under two different names at this point. This is akin to having an alias, but many may not be aware they are buying a pepper with two different names. It is just that the trademarked name can only be sold by Jon or Sue, or whoever trademarked the seed.

So, how do we safeguard against those aliases, unknown parentage, renaming, etc. and still have a good database?

When a vendor might rename the any pepper they choose, especially those that are early on in their development and they might sell an f1 as Scooby Doo, f2 of the same plant might be renamed Dragon Ball ZZ and some other vendor might get those same batches of seed and call them something else or trademark them under a different name.

When we have hybrids that are half baccatum and half chinense like Primo x Lemon Drop which is really a C. chinense x C. baccatum being sold as C. chinense as if they did not have any baccatum in them... totally ignoring the baccatum half of the genetics it is really hard to keep track of lineage and calculated percentages of parents if someone were to use that pepper to hybridize with.

Tepin x Lemon Drop... how many have seen that cross labeled as a simple C. annuum. Again, that cross is actually C. annuum 'Tepin' x C. baccatum 'Lemon Drop'... making it 50% baccatum and 50% annuum... yet it is sold as a simple annuum.

How many have seen a flower from one of these interspecific crosses with baccatum that shows baccatum markings in the flower at a later generation? If we can say we have, how do we reconcile that with calling an interspecific cross by a species name when it is clearly not?

Think about this cross now, [(C. chinense 'Primo' x C. baccatum 'Lemon Drop') sold as C. chinense x (C. annuum 'Tepin' x C. baccatum 'Lemon Drop') sold as C. annuum]...

We would have two plants one sold as C. chinense, but 50% baccatum in actuality. Another plant sold as C. annuum, but 50% baccatum in actuality.

The resulting babies in theory would be 50% baccatum, 25% chinense, 25% annuum, but both were simply being sold by the vendors as simple species as though they were intraspecific hybrids when they were in fact they are interspecific crosses and at this next step how would you name them... other than to name them as an interspecific hybrid....?

So, I applaud the idea and the hard work that goes into a database like you mention, but I think we have a lot more problems then simply not having a database.
 
There is a lot of mislabeling of the species. It will require research and quality control of the information for an ideal database of pepper varieties. Pimenta de neyde, which I use to cross, is often mislabeled as c.chinese. This is the reason I was thinking of creating a database. There is way too much misinformation.
 
I know I'm in the minority, but as a former web dev who now selectively whitelists JS and cookies... this doesn't load anything at all without JS enabled. Pure gray page. Nothing. A lot of the web depends on it now, but it's important to realize that when absolutely nothing on your site works without JS, you're adding both loading and processing time for everyone. And for mobile and slow-connection users, that can be a lot more significant that you might think.
 
As a curmudgeon now writing Clojure and going back to Python occasionally, if you want to work with people who know what they're doing, drop PHP. It's a garbage language, and the best framework in the world can't fix that. I spent nine years of my professional life with it, so I think I'm qualified to make that particularly harsh judgment.
 
I do think this is a good idea, and I'd mention that Redis is a solid choice for data models that aren't static or predictable. It's a project I'd love to pitch in for, if you were to go with a sane language and ditch the heavy front end.
 
internationalfish said:
I know I'm in the minority, but as a former web dev who now selectively whitelists JS and cookies... this doesn't load anything at all without JS enabled. Pure gray page. Nothing. A lot of the web depends on it now, but it's important to realize that when absolutely nothing on your site works without JS, you're adding both loading and processing time for everyone. And for mobile and slow-connection users, that can be a lot more significant that you might think.
 
As a curmudgeon now writing Clojure and going back to Python occasionally, if you want to work with people who know what they're doing, drop PHP. It's a garbage language, and the best framework in the world can't fix that. I spent nine years of my professional life with it, so I think I'm qualified to make that particularly harsh judgment.
 
I do think this is a good idea, and it's something that might lend itself well to redis for arbitrary fields. It's a project I'd love to pitch in for, if you were to go with a sane language and ditch the heavy front end.
Click to expand...
 
Ridiculous. Can't write SPAs without JS atm. If it's too heavy on the client, then we can use SSR. You're going to have primitive sites that make too many requests without JS. Python isn't pretty either, so I wouldn't crap on php.
 
Dulac said:
Ridiculous. Can't write SPAs without JS atm. If it's too heavy on the client, then we can use SSR. You're going to have primitive sites that make too many requests without JS. Python isn't pretty either, so I wouldn't crap on php.
Click to expand...
 
Haha. First, I didn't say no JS; I said if your site 100% does not work without JS, you've shat the bed. Python has its warts, absolutely, but saying "x isn't perfect so don't criticize y" is truly ridiculous. PHP is fundamentally garbage from a language design standpoint. JS really isn't a lot better, and using it on the server might have been the worst web development idea in the last decade... it seems to me you could benefit from expanding your experience a bit. I made the same kind of arguments before I actually invested myself in learning tools that suck a lot less.
 
SPAs are a terrible idea from the standpoints of usability, indexability, testability, etc... in the first place, so yeah, also not a very compelling point.
 
You must log in or register to reply here.
Back
Top