Skip to Content.
Sympa Menu

piw - Re: [piw] Re: [pcplantdb] relationships implementation

piw AT lists.ibiblio.org

Subject: Permaculture Information Web

List archive

Chronological Thread  
  • From: Richard Morris <webmaster AT pfaf.org>
  • To: Permaculture Information Web <piw AT lists.ibiblio.org>
  • Cc: PCPLANTDB <pcplantdb AT lists.ibiblio.org>
  • Subject: Re: [piw] Re: [pcplantdb] relationships implementation
  • Date: Sat, 26 Mar 2005 10:41:18 +0000

Chad Knepp wrote:
Hi all,

Here is longish response to Rich M., Heide, John S. and Bear about
relationships.

This is pretty much exactly how things are already. Some of the minor
differences from your description is that I give use numbers for
object ids not real word names. The actual xml (kfml) for doing links
like above is: <link plant="6047">Salix Alba</link>. The html client
(Html.py) converts this into <a
href="http://permaculture.info/cgi-bin/eden?plant=6047";>Salix
Alba</a>. You can even embed searches with things like <link
search="Salix alba">Look for white willow</link>. Current objects include
plants, authors, comments, uses, references, and [comming soon]
relationships.

Sounds fine. Personal preference in having the name of some thing
rather than a number in a link. Main advantage is that
it makes the URL's human readable, this can make it easier
for other sites to have incoming links.

Well, even if the relationship is one element relating to another
element, in terms of table structure, I don't think we can have any
unique columns. For example:

object | relationship | object
---------------------------------
plant A guild member Plant A guild
plant A guild member Plant B guild
plant A guild member Plant C guild
plant B guild member Plant B guild
plant C guild member Plant C guild
plant D guild member Plant B guild

... is really a many to many table. Although each row is unique,
every column has duplicates.

Indeed. This table structure gives the power of many to many
relationships, however each link (relationship?) is just one to one.

How about this? No better, but lighter.

object | relationship
-----------------------
plant A Plant A guild member plant A Plant B guild member plant A Plant C guild member plant B Plant B guild member plant C Plant C guild member plant D Plant B guild member
If i'm understanding correctly there will be object's

Plant A, Plant B, ...
Plant A Guild, Plant B Guild, ...

The simplest form is

object | links_to
-------------------
plant A | Plant A Guild
plant A | Plant B Guild
plant B | Plant B Guild

This assumes that a link to a guild implies
its a guild member.

Th question is do we want a facility where its posible to annotate a link.

In the past I've played with two different types of
guild membership: Natural Guild Member (i.e. exists in a natural setting) and Cultivated Guild Member (suitable for a human constructed guild). Both would link to same page.

> object | relationship
> -----------------------
> plant A Plant A guild member
> plant A Plant B guild member

Does not seem clean enough to me. Some how there
has to be code to translate
'Plant A guild member' into a link to 'Plant A guild'.
Probably labled 'Guild Member'.

This is close to del.icio.us style loose tagging. I kind of like this
from a weight standpoint.

Yes the del.icio.us stuff is nice.
Seems to allow people to tag links see http://del.icio.us/pfafrich
for some examples.

Thing I don't like about del.icio.us is that I'd like to
add a bit more text than just a title/description to a link.

If I'm doing a link to permaculture.info I want to record
the url, title for link, but also some brief text describing the site.

> 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">

Well, this adds weight to the object. There are several different
ways we can approach relationship implementation, from heavy to light.
I was favoring a light weight approach because I suspect it would be
more flexible in the long run (and we have so many to add).

Yes. Light is good. descript could be a bit ott.

I don't see much problem in having unused fields in DB.
Space and speed are not really issues. Expresability it.

> Heavier
objects could include lists which is what I think you're suggesting.

Yes lists of links are useful.

It would be easy enough to allow attaching a comment to the
relationship that I don't think relationships need built in
descriptions. This keeps it light and gets at what I think you
wanted.

Yep, comment could be added in suronding text.

> > o Should relationships be owned? editable? moderateable?

I was thinking they would be completely separate objects. By not
being owned, relationships could be submitted but not edited or
deleted. They could be moderated with or with out ownership, but
moderation adds a lot of weight...
> > 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.

Wait, you're not supposed to add more complexity to my question,
you're supposed to answer it;-)

> > 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.

By class do you mean relationship? The current DB is pretty much one
table per object type with some exceptions to achieve a higher level
of normalization.

By class i'm meaning object type.

> 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

This would be a fairly heavy weight implementation, and looks like it
would require some interaction.
Yep, first two

`Contributer` TINYTEXT NOT NULL,
# "Who submitted this record"
`ContribDate` TIMESTAMP,
# "When it was submitted"

are good, rest is dropable.

I don't think the coding part will be hard. I'm mostly worried about
having millions of heavy weight objects and the load of searching
through them all.

Ah I see the problem. Therotically havings complex objects
in tables should not be a problem. Whats important is the
indicies (in an SQL sense). Keep the indexed things light
and we should have good performance.

Anyway, this is why I've been pushing the idea of XMLizing this part
of the data. [32] would become [<link reference="32">32</link>] or
something.

Agree with Chad here.

Getting closer.

I guess we need to move towards a human and machine readable
spec for how comments and relationships are implemented and work.
Human readable so everyone here can undersatand what were getting at.
Machine readable as it will make thing precise so we don't miss interpret each other.

Rich





Archive powered by MHonArc 2.6.24.

Top of Page