-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create document describing query requirements for db #2
Comments
From Nicole:
The above concerns raise an interesting point - there needs to be a way to formalize a "relationship" between a plant characteristic and a specific environmental constraint. It needs to be abstract enough to handle the above questions, and more. Also, the terms "constraint" and "relationship" are overloaded in sql jargon, and this is NOT a advocating for the specific use of those. They may or may not be deemed appropriate at a later time. |
This also reminds me of the landscape designer piet oudolf who is known for provocative seasonal landscapes. That kind of planning requires a more comprehensive and dynamic approach to plant data. |
I would also call out cultivars designed to display specific types of variegated foliage. Variegated foliage is known to change if the environment it was originally cultivated or hybridized in deviates enough. I think this is specific to light requirements, as there is a relationship to variegated patterns and light intensity. Some speckled aucuba I believe will revert to previous non speckled forms if the intensity changes. They tend to be recommended for growth in dappled light, but can also work in direct sunlight. |
I should also specify that this speaks only to cloning, e.g. Vegetative propagation, root, rhizome, stolon etc. Seeds will naturally deviate over time so this presents a completely different set of changes that are not addressed here. |
Specific to the seasonal planting, there seems to be a few areas that need to be represented:
We might and also find permutations of {bark, flower, foliage } * {color, shape, pattern } but that might be a bit overkill. I'm not sure. |
https://en.m.wikipedia.org/wiki/Floral_formula This is an interesting approach to solving the complexity of just flowers from a botanist perspective. It kind of is a domain specific language of sorts. Just putting it here for reference. |
@nicolesimon discuss environmental aspects |
I'm currently working on a plant database and one of the important factors in getting the SCHEMA right is making sure it can accommodate various types of questions.
There are two pieces of criteria I would use to judge "correctness":
does it answer the question fully, assuming the data is present? obviously if the data is not available, no schema would work, so I would ignore that as a degenerate case.
assuming the previous, does it do so in a reasonable timeframe? If the query is too slow it's not useful
is it organized in such a way that it doesn't require complex querying? E.g. If sql, is it not so normalized that common query scenarios require a complex jumble of joins?
With that criteria in mind, it is important to enumerate all the likely scenarios. Many of them would be categorical. The few categories I have so far are below. Note that these should eventually be made into questions.
horticulture
landscape design
genetics
general
climate change
@nicolesimon After some discussion, I think we'll move forward with a graph model database, at least in terms of initial exploration. We can leverage document or relational databases if we feel it's inappropriate, but it seems highly advantageous for the complex relationships and idiosyncracies we have to support.
We will need to solve #6, #7, #8 #4 as well, and possibly look at #5 to achieve this prototype.
The text was updated successfully, but these errors were encountered: