Skip to Content.
Sympa Menu

pcplantdb - Re: [pcplantdb] relationships implementation

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Bear Kaufmann <bear@ursine-design.com>
  • To: Permaculture Plant Database <pcplantdb@lists.ibiblio.org>
  • Subject: Re: [pcplantdb] relationships implementation
  • Date: Sat, 26 Mar 2005 21:50:09 -0800

Back in town...

I'd also be inclined to try to have relationships, comments, etc be a
subclass of one primary object type. Comments have some specific forms
of relationships to objects and other comments (always a tree form, no
network). The superclass has owner data, source?, date stamp, handles
relationships, outputs the object for full text search table(?), etc.

Right, comment trees can be implemented by just having a parent.
Relationships would need to have multiple linkages or a functionally
equivalent structure. Yes, relationships and comments seem to have a
lot in common, which is why I've been asking what the difference is.
Not really understanding your last sentence.

Ok, last paragraph might have been confusing. I was thinking in the OO frame of mind, and that since there might be great similarities between the relationship and comment types, that the commonalities could be handled in a superclass, with the specifics handled in sub-classes. I haven't applied OO to a relational DB system, so I don't know how much the idea would help the situation...I suppose it first depends on were we decide comments and relationships relate...

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. Although it is a concern to mark up the data in ways that
may decrease its accessibility '[32]' is a "mark up" and a horribly
inaccessible one at the moment. The other alternative of removing
them and externalizing the reference (in another table) does reduce
some of the information (the references often pertain to a particular
sentence in the text). This is kind of offtopic, but I'm open to
talking about this more/again.


Chad wrote:
OK, getting close, only 30 matches...
Pea-shaped flower...
2 matches. Locust...(racking my own limited DB... :-P )

This explains faceted searching better to me. Yes this would be some
interesting coding. How do you know what to start with? Like what
start with flower color and not flower shape? Or do you start with
all of the options and it just continues to narrow the resuts?...
Yes, you start with all the options, and narrow to the results. So you (the user) has the option to choose the order/traits. The traits you search by wouldn't have to be limited to a predetermined sequence, or just taxonomic traits. You could use the system to find out what a plant is (use the taxonomic traits), or find one that suites the site conditions (ie, and produces fruit).

The system would seem to have limited value when searching for very specific ranges (35 feet high)...but since a good deal of the data seems to be limited to a few values (ph = low, medium, high, habit =...., soil =....) it would seem to work...

Which some systems that throw up the whole slew of criteria for you to select from (ie USDA plants), a user might be tempted to click off: drought tolerant, fruit producing, fast growing, nitrogen fixing, fodder crop, to be saddened when clicking search they get "Your Search Produced 0 (Zero) Results". The faceted method will lead you down paths that actually exist...terms with less then one match in the subset are dropped...you learn quickly that a nitrogen fixer limits the other available traits to choose from.

The crux of the coding for the system would seem to be taking a result set and pulling the unique values out of it, and dropping any that aren't in the set...

Not high priority, but seems like a system that's implementable before tackling GBI's...

Cheers,
Bear





Archive powered by MHonArc 2.6.24.

Top of Page