Permaculture Database

[Paul d'Aoust <paul@heliosville.com>]

Hi, Jedd. My secret feeling is that, although RDF triples are quite a
thrilling and versatile concept, I just can't get my head around them,
and they may be very hard to abstract into something extremely simple
for the average permie to use. I'm trying to keep my mind open; that's
why I'm attempting to understand this RDF thing.

I think the intent of RDF is ostensibly to make it as flexible as
possible, to prevent present design choices from imposing future
restrictions, and the complexity is not in the data itself, but in the
richness of potential relationships. Sounds kinda permaculturey, eh?

That having been said, RDF seems like it's too versatile -- so versatile
that it becomes unhelpful for people who are trying to create things
that 'Just Work'.

The 'Semantic Web' seems to be the next big thing to make the
information on the Internet easier to find and understand, but maybe we
could simply create an app that's useful NOW, and worry about presenting
its data in RDF format somewhere down the road.

And I still don't know how you could create the weighted relationships
that we're talking about in RDF. It seems like you'd have to add an
extra dimension that would make the complexity spiral out of control.

There's a trend in web app development right now that stresses
simplicity, straightforwardness, and utility. I think that's what we
should concentrate on, rather than making it some crazy powerful
database that does everything. And if we could make the app intelligent,
like you say, and extrapolate data from a handful of very simple tables,
then it might be quite powerful.

I agree that 3-way and n-way data should be discovered by the
application -- however, I think that we should also have a 'guild'
feature which would allow a person to say, 'hey, this collection of
[walnut, hackberry, chicken] is a tried-and-true guild and it works for
me,' and then have it be an entity in its own right that people can
comment on. Just nice to have that human credibility in addition to all
the relationships the computer exposes.

I have more thoughts, but I'm actually supposed to be working right
now :-)

Anyway, thanks for saying some things that I secretly really find
delightful -- cuz I did bring up the RDF idea, but honestly I was scared
of it and didn't instinctively like it, because it's too confusing.

Paul d'Aoust



On mié, 2010-02-03 at 21:30 +0000, jedd wrote: 
> 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.
> _______________________________________________
> pcdb mailing list
> pcdb@lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/pcdb