Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] relationships implementation

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Richard Morris <webmaster@pfaf.org>
  • To: Permaculture Plant Database <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] relationships implementation
  • Date: Wed, 23 Mar 2005 00:20:47 +0000

Chad Knepp wrote:

Need some help here,

Although we have talked about it before, I'm still sort of unclear on
what relationships are to the extent that I'm not coming up with an
implementation. Can folks suggest some stuff? Specifically I think
it would help me to hear some fantasies as to how they might work; as
in you define a relationship this way with these elements and when you
search for this or are looking at that you get a path to the
relationship.

Here are some questions that might help.

o Since we only have plants at the moment, how should we represent
relationships with non-plant elements (animals)?

This is a sort of name space issue, i.e. how do we refer
to objects.

One option is to give each object a class.
Typical classes could be Plant, Animal, Location, Habitat,
Guild,User. Then we could refer to an object as
Plant:Salix_alba or Animal:Bumble_Bee.
In a URL this could be http://permaculture.info/plants.py?Salix+alba
or
http://permaculture.info/search.py?class=plant&name=Salix+alba
Internally we don't need to store the full url, just the
class and the object name. (better as it allows us to
change the exact structure of a url later).

The alternative is a wiki style where everything is in the same namespace.
http://permaculture.info/search.py?Salix+alba
http://permaculture.info/search.py?Bumble+Bee

o What sorts of information should a relationship have? Things
like: A list of plants contained in the relationship. One [or more]
word[s] that describe[s] the relationship.

Main questions is a relationship one directional like a
<a href=...>
or bi birectional
<link source=... dest=...>

Also worth considering if is a 'one to one'
or 'one to many' relationship. I'd think we should just have 1 to 1 relationships.

If you want to have one to many relationships
then use an intermediaty object.
A typical example of a one to many relationship might be a guild which has lots of plants.
Each plant could refer to the guild (one relationship per plant)
and the guild, a seperate object in its own right.
<link source="Plant:Salix+alba" dest="Guild:Willow+Guild">
<link source="Plant:Allumn+cepa" dest="Guild:Willow+Guild">

Do do think its wise to allow relationships to have a type
and also posibly a description.
<link source="Plant:Salix+alba" dest="Guild:Willow+Guild"
type="Guild Member" descript="main plant in guild">

o Should relationships be owned? editable? moderateable?

Assuming that the relationship was part of a comment. Then it would
have the have the same owership and permisions as the comment.

In the past I've played with having everything with an owner.

o What's the difference between a quality/attribute and a
relationship? For example is nitrogen fixing a relationship or an
attribute? What about alleopathic (sp?) properties?

I'd say nitrogen fixing is an attribute, but
habitat types, plant uses are relationships.
I'd be very inclined to have Habitats and Uses as top level classes.
So its posible to have a page per habitat describing the habitat
and listing the plants in that habitat.

o What's the difference between a comment and a relationship?

Or even, plant, comment, relationship.

o How is a relationship different from a natural plant community?

Links and nodes. In a graph theory way of looking at it
a natural plant community is a 'node' and relationships are 'links' to
and from that node.

Also the techie folks on the list can feel free to chime in with
suggested schema (relational/SQL stuff). Remember different
relationships are probably going to be one-to-one, one-to-many,
many-to-one, and many-to-many.

Bigee, could have one tabel per class, or one big table with a class field.

Relationships are probably best in a separate table (similar
to 'edible use details' but with a couple of other fields.

In the past I've have a concept of a contribution, similar
to your comment idea. Everything in the database
had the following fields

`Contributer` TINYTEXT NOT NULL,
# "Who submitted this record","Must corespond to an entry in the users table",NULL
`ContribDate` TIMESTAMP,
# "When it was submitted","Entering NULL will insert the current date",NULL
`ContribAction` Enum("Req Add","Req Update","Req Del") NULL,
# NULL,"What to do with the record, i.e. instruction for the
editors
# Add means just add some info
# Update means a change in info
# Delete indicates that some info might be incorect","Might at some later date want to change the ENUM for this"
`ContribNotes` TEXT,
# "Notes supporting this contribution",NULL,NULL
`ContribRefs` TEXT
# "references to support this contribution",
# "a comma seperated list of reference codes in the references
table",NULL

Hope that helps

Rich






Archive powered by MHonArc 2.6.24.

Top of Page