Skip to Content.
Sympa Menu

pcdb - Re: [pcdb] Modelling RDF in relational databases

pcdb@lists.ibiblio.org

Subject: Permaculture Database

List archive

Chronological Thread  
  • From: jedd <jedd@progsoc.org>
  • To: Permaculture Database <pcdb@lists.ibiblio.org>
  • Subject: Re: [pcdb] Modelling RDF in relational databases
  • Date: Wed, 3 Feb 2010 21:30:58 +0000

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.




Archive powered by MHonArc 2.6.24.

Top of Page