Permaculture Database

[jedd <jedd@progsoc.org>]

 Hi Paul,

 I think I looked at RDF and related subjects a while back, as the
 stuff in those links was ringing a few bells for me.

 Actually, reading what you're suggesting here, and talking about
 picking another language - I'm reminded of how strong PROLOG
 would be for this kind of material.  (I've tried to learn Python a
 little while ago, but got distracted.  PHP's always a safe choice,
 just because of the sheer number of people that know it.)

 I'm not convinced that we would be better off, however, turning
 all relationships into triples.  I think that it's better to keep the
 data really very basic, and put the intelligence into the app - the
 front end, as it were - as this lets you do more and more interesting
 things with the data as time goes on.  I can't think of any actual
 examples, but I fear that making the underlying data more complex
 and sophisticated would make it harder to use it in different ways
 (to originally intended) later on.

 This is gut feel stuff, however.

 More specifically ...

On Wednesday 20 January 2010 21:59:34 Paul d'Aoust wrote:
> ... (stated in a triple, that'd be something like 'duck needs 
> openwater').  Schema administrators would be able to create
> and/or import vocabularies and schemas -- essentially, be able
> to make new classes available for everyone else to use.
> 
> There could be weighted opinions -- e.g., if there are fifty
> 'tomato needs fullsun' opinions, and only five 'tomato
> isokaywith partialsun', it shows the tomato's sun needs as
> mostly full sun. (Honestly, I'm not sure how this will work,
> because as far as I know, RDF doesn't allow you to define
> the strength of a relationship -- does anyone know how you
> could model something like this? It would be very confusing
> to create a vocabulary like 'hates', 'dislikes', 'neutral',
> 'wants', 'needs', and then try to explain to the computer
> that this is supposed to be a weighting system. Ideally, you
> could specify an attribute and an object, like 'tomato needs
> 6 sunhours'. I don't think that's valid RDF though?)

 The way I've been pondering doing it is to have an entity such
 as a tomato plant.  I've pondered having climatic/weather
 things treated separately, but might just lump them in with all
 non-organic entities (like sheds, ponds, fences, water tanks),
 but in any case they're an entity of some sort.

 Then I have a relationship that exists - much as you've described,
 but it has a value.  I've considered just -10 thru +10.  This would
 be one-way - that is I'd have this as a row in the relationship
 table:
 entityA
 relationship_type (eg. provides, impinges, improves flavour)
 value (-10 to +10)
 entityB

 Because I like examples, I'll throw in a couple here.
 A walnut tree impinges on an apple tree.

 (Proximity is handled elsewhere.)

 In this example, an apple has no impact on a walnut, so there's just
 one row to describe the interaction between the two entities.  But
 consider .. hmm .. let's say the alleged basil and tomato synergy.

 I'd have two rows to show this - each row is a direction from
 entityA to entityB.

 Yes, for any given entity you have to look in two columns, but I
 think it provides for a more concise mapping of relationships.

 For three(+)-way relationships - I think you pull that information
 out in the front-end.  I know there's been talk of mapping guilds
 directly into the underlying data - but for me that's anathema,
 as they should become apparent from empirical data that's put
 into the system.  By using observations, we can determine if some
 of the commonly believed guilds actually do work, but more importantly
 we'll get to find out new ones.

 For observational data - that is, the VALUE in the above relationship,
 but also things like productivity (by volume or mass) of plants and
 animals in various environments - I will have ways of putting that
 information in that will map back to the user's region and climate,
 as well as timing within the seasons.

 Beyond this it gets *really* fuzzy in my head, though.


> Taxonomical classes (e.g., kingdom, order, family, tribe, class, genus,
> species, cultivar)

 I have determined 21 of these buggers in my schema so far!

 I'm thrown by the fact that phylum and division mean the same
 thing/level, but one is used by botanists, the other by zoologists.

> Plant
> Animal

 I hadn't thought about this before - my initial reaction is that it's
 done higher up - in the application layer.  The DB should contain
 only uniquely identifying information about an entity, and the
 relationships between them.  Chooks to comfrey, say.

 I'm unsure how you map this kind of construct into the schema, though,
 without it becoming a mess (in other words, how do you do this
 kind of thing, and allow for more of the same later).

> Geolocation (there are already ontologies in use out there)

 Still can't make head nor tail of POINTs in MySQL.

 Jedd.