[pcplantdb] relationships implementation
Bear Kaufmann
bear at ursine-design.com
Sun Mar 27 00:50:09 EST 2005
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
More information about the pcplantdb
mailing list