pcplantdb

[Chad Knepp <pyg@galatea.org>]

Bear K writes:
 > Think we can set up a CVS server and edit/append to Richard's DTD at 
 > some point?

CVS is already set up on Ibiblio with
CVSROOT=/export/sunsite/users/pyg/cvsroot/

Something like 'export CVSROOT=/export/sunsite/users/pyg/cvsroot/'
(put this in your .bashrc) followed by 'cvs co eden' should get you
the latest greatest version. 'cvs ci -m "note of changes made"' should
check your changes back in.  My start of the dtd (3 lines) is
kfml.dtd.  Feel free to make changes, etc.  There isn't a remote cvs
(pserver) set up and I don't really even want one for security
reasons.  Permissions should be correct for members in the piw group
(currently only John H., Bear, and myself) to use cvs.  If you are
going to start making changes to things I'm actively working on I'd
like to know first... this is mostly eden/cgi-bin/Eden/*.py

 > > The concept of being able to attach a comment to every/any 'object' is
 > > a concept I am quite into.  Defining object granularity as a sentence
 > > is a little smaller than I had in mind.  I was thinking more along the
 > > lines of a comment being the smallest object, but this could be
 > > multiple paragraphs.
 > Yeah, thats fine. Seems like current text blobs are 1-4 sentences per 
 > reference...
 > Also, can we assume all text prior to a reference [#] is from that 
 > source?

You'd have to ask Ken I guess.  This kind of stuff is completely
dependent on the author.  Some people may write a comment with 10
paragraphs and 30 references.

 > > While I agree that knowing the source of information is important, I
 > > personally have more faith in the reports of personal experience by
 > > Hemenway, Holmgren, Pittman, London, etc. than a reference to a book.
 > > These folks already have reputations.  I also suspect that from this
 > > point on most/all of the information we will accumulate will not be
 > > researched from books like Ken Fern did with PFAF.  I've said all this
 > > before...
 > I didn't mean to imply that books are more valid. Just that the current 
 > DB refers to books. Thus the "comments" should allow a source property, 
 > which might be a book, or the person entering it themselves.

How about a sources property allowing 1 or more sources for the
information contained in the comment.  If we allow some markup, we can
do away with that and let the authors note sources inline like Ken's
[#] markup.  Note: Ken's text has markup in it already that we need to
do something about, either remove it and add source properties to text
or change it to an inline XML markup.

 >  From john s:
 > > Hmmm, relation characteristics like the "root zone (in)compatible" 
 > > ones and similar could be elaborated by linking to relevant 
 > > plants...so, for a given plant, select a relevant word/phrase, then 
 > > possibly elaborate in comment and/or link to relevant other plants 
 > > that "finish the phrase."
 > >
 > > So something with a shallow root zone would have an attribute 'root 
 > > zone compatible with' and linkages to plants with deep root zones 
 > > (ideally ones that also had other relevant relations...this is just an 
 > > off-the-cuff example, remember? ;-)
 > 
 > This brings up 2 things:
 > First, it seems like having to manually create linkages between plants 
 > with short and deep root zones is overly laborious. I'd prefer to see a 
 > query used on these, something that could look at species 1, find the 
 > root zone, then find plants with zones deeper/etc then the species. 
 > Having to manually create links is going to mean making a link that 
 > probably has more judgements about the relationship then just 
 > rhizosphere. I'd prefer to see queries narrow the options down with 
 > more terms from as wide a selection as possible.

I think you are saying that plants need a root zone attribute, kind of
like height, although this would probably be multiple attributes, one
for the shape, one for the depth, etc...

 > On the other hand, I'd love for there to be a way for authorship of 
 > "case study" relationship networks that are in the real world. Tagging 
 > a connection with a UID for a network, and querying for that UID to get 
 > the nodes. Something that both adds data to the whole DB, while also 
 > being able to be viewed as a real network. The Apple Guild, etc. If for 
 > example the DB expands beyond plants at some point, the networks from 
 > ZERI projects could be added, or the Soil Food Webs from E. Ingram 
 > could get added in, or of course new guild combos from the PC 
 > community. These ARE relationships that have been discovered and 
 > applied by real people.
 > 
 > Then at some point in the future, someone could build the network in a 
 > TG client, export it as RDF, and publish it on their blog, commenting 
 > on how it's worked and how they found it. They ping PIW a la trackback, 
 > and PIW notes and adds the relationships to the DB.
 > 
 > OK, hand wants to stop typing.
 > 
 > Cheers,
 > Bear

The thing that impressed me from the folksomines (sp?) paper was that
making the creation of tags/relationships easy and accessible is going
to be vital for actually getting our larger audience/authorship
involved in creating these linkages.

-- 
Chad Knepp
python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'