Permaculture Information Web

[Richard Morris <webmaster AT pfaf.org>]

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