auto-generate edible plant parts

[BrittanyBunk]

instead of writing in what's edible and what's not - what if there's an auto-generation of all this information when clicking on the species? That way it saves writing in, but also people don't waste what they don't know about - knowing gives more capability.

[ezwelty]

@BrittanyBunk What do you mean by "clicking on the species"?

Generally I think I agree with you – we should provide more information about each species. I would suggest the following:

• Link Falling Fruit types to entries in the Plants for a Future (PFAF) database.
• Populate list of edible plant parts and uses from the PFAF database (license / permission permitting) or at least include a link to the PFAF plant page (as we have already done for Wikipedia, etc).

In the longer term, we should have a profile page for each Falling Fruit type. At the moment, we don't even display all the information we actually have about each type in the database – in particular common names in different languages.

[pukallus]

Writing profile pages for each Type is a huge body of work. One approach could be to set up a RAG based on something like PFAF to anchor GPT prior to auto-generation of the content. That way the generalist knowledge of GPT can be augmented with the specialist knowledge of a credible database.

I think you would script the generation of each profile once initially for the main profile body. "Live" advice could insert the user's location (or location of interest) and date into the context window to give more specific and current information - for example, whether the Type is in currently season at the user's location. A step further could perhaps use API calls external climatic/weather sources to indicate whether fruiting is likely to be affected by abnormal conditions.

[ezwelty]

@pukallus Honestly, for the type profile pages, I was imagining something simpler, without a narrative description. Rather, displaying the available structured information associated to each type (like common names in different languages or the list of edible parts pulled from the PFAF database), links to parent and children types, map stats, user photos, and content from the associated Wikipedia page. My desire for having edible types as structured data is that it could then power type filters (e.g. "show me all plants with edible flowers").

I'm fascinated by your suggestion, however, and I can see how these descriptions could be more useful to our users than Wikipedia content, which does not specifically cater to foragers.

Seasonality filtering / prediction is a long-discussed subject (see https://github.com/orgs/falling-fruit/discussions/101) and a lot of work was done last summer by a student group (https://github.com/falling-fruit/dfg-seasons) to build predictive models (in Python) for types for which enough dated phenology observations exist (unfortunately I haven't had time to dig into this and put these models into production, in case this is something that might interest you?). My hunch is that this approach would outperform GPT, but it would be worth testing this assumption.

[ezwelty]

The PFAF license does not allow displaying their information in other apps, but we can link to their plant profile pages and use their data internally (e.g. to curate the forager category / default type filter). An alternative would be to scrape data from https://tropical.theferns.info, the original basis for the PFAF database, which is openly licensed (I emailed them about a machine-readable format and received no reply).