pcplantdb

[imam@saleema.fsnet.co.uk]

I'm resigning from this list at the moment as I can't contribute anything technically. The content currently is all above my head. Good luck with it and no doubt I'll get involved later

Saleema

> Message date : Jun 30 2004, 09:09 PM
> From : "Chad Knepp"
> To : pcplantdb@lists.ibiblio.org
> Copy to :
> Subject : [pcplantdb] HG
> Lawrence F. London, Jr. writes:
> > Chad Knepp wrote:
> >
> > > o I am super excited and would love to dive into the design stuff
> > > immediately and off the clock. It would probably be nice to have a
> > > tech list for this. Lawrence?
> >
> > Can do, immediately. pcplantdb-tech@lists.ibiblio.org? or something
> > else perhaps that includes more than just plant information in a
> > permaculture database? maybe pcdb-tech@lists.ibiblio.org?
> >
> > As soon as you decide on a name and let me know I will fire off a
> > request; we will probably have our list within a week.
> >
> >
>
> How about hg@ or hg-tech@? Actually I don't think the name matters
> much. Whatever you pick is fine.
>
> Richard Morris writes:
> >
> >
> > The actual grant app and jim's feedback may have some baring on
> > feature set.
> >
> > For me its
> > 1) A plant database where users can add new information about a
> > plant, and add whole new plants. If we can do that and nothing
> > else it will be a job well done.
> >
> > Before we begin I think we need:
> > A CVS tree for the code (source forge sounds good to me
> > I'd be happy to set this up)
>
> Go for it. Might as well get the infrastructure set up early so we
> don't have waiting when we get in motion.
>
> > Possibly a wiki page for the specifications
> > (i.e. something we can all contribute to and
> > which will evolve with time)
>
> I personally dislike Wikis but this sounds ok. We do need some public
> repository of specifications and documentation about the project.
>
> > A project description page. Something that
> > new people can read to get upto speed on the project.
>
> Also as above.
>
> > Stuff I think should be in there, but not core
> >
> > - extensible, easy to add new features at later date
> > (e.g. so we can add a "folklaw" section, or
> > vote for plants)
>
> I think this is a core element and will only be as successful as our
> OO design is correct. This is super important and something I'm
> constantly turning around in my subconscious that occasionally
> surfaces as interesting possibilities. One of them was that as a
> sufficiently generic tool set HG could actually provided a similar
> service to other sub-communities. My friend had mentioned that the
> home-brewing list he was subscribed to had lots of great info (just
> like the permacutlure list) that was promptly forgotten and repeated.
> I can see HG being a Wiki tool better than a Wiki for specialized
> information. Anyway, I don't think that creating and distributing a
> generalized tool should be a part of the current project, but possibly
> something that could be worked backward to later on.
>
> > - full history of additions. So we can keep track
> > of who added what.
>
> Also essential if only to accurately preserve copyright info. This is
> also trivial to implement for a smallish amount of activity, but may
> need some sort of compression for a lot of use, like when the
> changelog grows larger than the rest of the data. Using some sort of
> *lossy* compression like dropping the actual content/nature of the
> change/contribution and merely attributing copyrights on the object to
> the author would solve the size problem at the expense of the
> information loss.
>
> > - buz word complience. Some sort of XML output,
> > rss/atom/rdf so its easy for third parties to
> > access the data.
>
> I've been thinking more about the role of XML in the project and yes,
> it would be nice and very doable to translate output to rss. This
> doesn't seem as important to do as soon as some other things.
>
> What has occurred to me is that one of the hardest and most important
> parts of the client toolset is the authoring/collaboration part. I
> think it makes complete and total sense for the client to generate
> this as an XML document and that the internal data elements all be in
> this ML. In Eden I made up something I called KFML that was a tiny
> subset of HTML with an additional tag for internal links like a Wiki's
> CapitolWord. Another [minor] feature of the client would be
> translating this internal ML to something viewable; like HTML if the
> client platform is a browser.
>
> Anyway I'm hoping I won't have much to do with all that so I hope you
> are getting excited about writing [or adopting] a dtd and a validator
> that can point out mistakes in the ML to the author. Sound like fun?
>
> > - guilds/relationships. I guess we'll need to do
> > something on this line to keep funders happy,
> > initially I think something simple. (I'm happy
> > to work on this aspect)
> >
> > - cool gui interface. Thinkpad type stuff. Again
> > we probably need something on this line and I'm
> > happy to work on this.
>
> I've actually had some more ideas on how to backend something for a
> graph based interface that doesn't require any natural plant
> communties. Although it would require a bit of effort I think we
> could look at similarity of certain qualities between plants and
> display the relationship of respective similarities visually. This
> wouldn't really design a guild but it could allow visual exploration
> of plants based on user chosen qualities and even importance of
> qualities.
>
> It is also possible to create a virtual/AI model of a guild and
> populate it randomly or with a similarities based algorithm.
> Something like a tree guild would require a central tree with an
> understory of different sizes or something. One could also create a
> generic aquaculture guild and so on. This kind of thing seems MAJOR
> HARD and although I love challenges I don't think we should try to go
> here immediately.
>
> > - picture uploads.
>
> Certainly and other media types as well such as articles. This is
> were the internal XML gets interesting depending on how much formating
> it allows the authors. Do you allow content to have embedded images
> or do you just link to them. Allowing authors to specify formating
> like embedded images may make for a nicer overall read, but opens up
> the possibility of really bad formating that detracts from the overall
> accessibility. I think allowing re-edits and having moderation will
> ensure that this doesn't persist though. Allowing formating options
> also makes WYSIWYG clients a lot more complicated. Lots to think
> about...
>
> > In my dreams:
> >
> > - votes/rating system for plants.
> > - shared Links/contacts/events databases.
> > - etc.....
> >
> > > o Implementation details: After we have point 1 of the feature set,
> > > we need to figure out who is doing what and how. The how is
> > > especially important when there is overlap between folks on the
> > > what.
> > >
> > > o Licensing: We need to agree on a license or licenses. I am
> > > completely open to suggestion, but I recommend the code base be
> > > under the GPL and the data set be under the CC BY-SA or BY-NC-SA.
> > >
> > There is now a CC-GPL license, which is basically GPL
> > but with machine readable metadata. This may be more
> > compatable with the dataset. I'd much prefer CC BY-NA-SA
> > to CC BY-SA for the dataset.
>
> If we use the PFAF dataset we will probably have to use the BY-NC-SA
> unless we can convince PFAF to drop the NC. The reason I don't think
> that the non-commercial clause is important is that if you are already
> providing the data in a free form no one needs to purchase commercial
> versions to get the information. If someone wants to publish a book
> with the information I think it is a win-win situation. They may make
> a little money on it, but having the information in a format we can't
> provide is a good thing for people that want to read a book with their
> breakfast and not bang on a keyboard. The only sticky situation I can
> foresee that not having the NC clause could lead to is if someone took
> the information and added additional but proprietary information and
> then sold it... kind of like the PFAF data with images. I don't think
> this would ever happen because if we have the entire permaculture
> community collaborating on it we would have a lock on all the good
> sources of information anyway. This is also why we don't have to buy
> the PFAF images, because I'm certain people will start taking pictures
> and uploading them as soon as we make it possible.
>
> I think the GPL is a very good license for code with an excellent
> legal track record. It wasn't really designed to cover other sorts of
> information so I think the data should be under either the LGPL or GPL
> documentation license or something else. Since the PFAF dataset is
> under a CC license and we are potentially going to incorporate it, it
> would be very straight forward to use that.
>
> One thing that hasn't been mentioned that I will say for the sake of
> thoroughness is the possibility of allowing the authors themselves to
> choose the sort of license they would like and offer a selection of
> licenses. This is actually the direction I was going with PCPDB but I
> think this is a bad idea because of the amount of internal accounting
> it would require in addition to the complexity of having a given
> object licensed under multiple licenses. An appropriate display of
> copyright would require us to show each and every license, possibly
> having more info about copyright than the plants or whatever. I also
> think that if we pick a reasonable license that folks will have no
> problem agreeing to contribute under it.
>
> Another thing for the sake of thoroughness is that the GPL isn't
> always compatible with non-free libraries and toolsets. This will not
> be a problem for me because I don't intend to use any non-free
> products. It is my understanding that the most everyone was on board
> with the idea of only using free software.
>
> So I propose that we consense on the following:
>
> Our project [HG] will license the code under the CC-GPL and the
> dataset under the CC-BY-NC-SA.
>
> So what do you all think? Now would be a good time to hear any
> additional concerns or comments you may have.
>
> > > o Project details: Uhh... things like a name, although this could be
> > > as hard choosing the color of paint I would love to start referring
> > > to it as something other than "project" or "our product". There
> > > are a host of other details that may actually be easily answered
> > > but I cannot immediately recall the answers.
> >
> > I've been refering to it as the "opensource/community (permaculture)
> > plant database". But a bit of a mouthfull.
>
> I'm going with HG... it's funky, short, and sweet! ...maybe it will
> stick. We should have something a little better to release though.
>
> >
>
> Stephanie Gerson writes:
> > Group Strategy and Plan of Action
>
> Wow this looks good. The estimation of times seems close to my own
> guesses.
>
> > Divided into 3 Tasks:
> > A) Software Development-to be executed by experienced Computer
> > Programmers and User-Interface Designers
> > B) Plant Research and Data Entry-data will be solicited and collected
> > through on-line Permaculture/Agriculture/Horticulture forums,
> > listservs, and communities; existing informational resources (books,
> > magazines, journals, etc.) and plant databases; Permaculture or
> > related conferences, and on-visits to developing or developed guilds
> > (many guild designers have already offered their expertise)
> > (C) Further Outreach/Dissemination-to be performed through the same
> > channels as data collection
>
> One thing that I suggested earlier as a possibility to stretch our
> funding was to not fund much or any authoring initially. Not sure
> where everyone is on that.
>
> > Stage 1 - Design, 1 month
> >
> > A1) Detailed technical spec to be drawn up. Inc: database schema, mockup
> > of user interface, selection of software environment.
> > B1) Format for information on plants to be agreed.
>
> Hmmm... seems to me that B1) is really part of of A1) specifically
> related to the database schema... unless you mean something like the
> XML format which still seems to be part of A1).
>
> I think that an important part of A1) is to be very clear on what we
> are creating but try and be quite flexible about the creation and
> allow a naturally evolving process. Even if we write 500 lines on
> database schema, I'm certain that it will be in at least some small
> way inappropriate to our needs within a month of development and it
> would a shame to kick ourselves in the shins by adhering to it. I
> think we can know where we are going and state that clearly but I'm
> not sure we can say now exactly how we are going to get there, so I
> think it's important to seperate elements of the design into goals and
> milestones and expect that the implementation will sort itself out as
> we go along. I also may be out on a limb here because I tend to be a
> kind of *dive in headfirst* sort of person.
>
> In terms of design I would like to focus on things like whether or not
> to try and include a moderation system in this incarnation and what it
> would look like. Should the client have its own editor? What kinds
> of things other than plants should we include if any? etc...
>
> > C1) Contacting partner organizations. Research into third party datasets.
> > For the above, we would like to have a 1 week physical meeting (ideally at
> > a Permaculture conference, in order to simultaneously collect information,
> > solicit participation from interested parties, and make contacts with
> > partner organizations).
> >
> >
> > Stage 2 - implementation, 3 months
> >
> > A2) Implementation of software. Core database engine and user interface.
> > B2) Collecting and inputting plant and guild data. Once this web resource
> > is available for input, this task will continue perpetually, carried out by
> > the resource's users. For purposes of devising a timeline, the initial
> > 'prototype' of the web resource will occur in Stage 2.
> > C2) Incorporating comments from partners.
> >
> >
> > Stage 3 - First working version, Testing, 1 month
> >
> > A3) Importation of plant data to main database. Initial
> > evaluation of database and user interface. Testing.
> > B3) Iteration of A3). More data collection. Editorial review of data.
> > C3) Incorporating third party datasets.
>
> I'm not sure what you mean by A3) but it would be nice to get the PFAF
> dataset in sooner than this in order to have something concrete to
> work with. I can make up dummy data but since it's not really much
> work to do it makes sence to me to merge in PFAF somewhere in the
> early-middle of stage 2. I estimate that this will take less than 40
> hours and represents a fabulous amount of info on 7000+ plants.
>
> > Stage 4 - Refinement, Production of first release candidate, 1 month
> >
> > A4) Refinement of software and interfaces.
> > B4) Iteration of B3).
> > C4) Outreach/dissemination activities. Database launch publicized.
> > The next project-participant meeting/Permaculture conference occurs.
> >
> >
> > Stage 5 - Maintenance of live version, Processing Feedback, 5 months
> >
> > A5) Ongoing maintenance. At this stage main software track decreases in
> > time
> > Involvement. However continual maintenance and improvements are needed one
> > week/month for remainder of grant period. Ultimately, the web resource
> > should be self-sustainable, not requiring a permanent salaried moderator (a
> > responsibility we will assume throughout the grant period), but instead
> > depending on the interest and volunteer efforts of its constituents.
> > B5) Editorial control of data input by users.
> >
> >
> > Stage 6 - Project Conclusion, 1 month
> >
> > C6) Begin spec for next phase. Complete final report for funding
> > source(s).
>
> I am interested in starting A1) as soon as John is back online and we
> have a tech specific list. I'm not really into doing the conference
> call thing and being spread around the globe might be something of a
> scheduling problem. Does anybody here use instant messaging? I can
> see that as having some potential and you can't beat the price.
>
> So when are we fully funded? When are we to officially start, as in,
> when do I start tracking hours? Also what kinds of activities are
> billable? I could use more info. about the business side of things as
> I'm not really sure what the norms are.
>
> --
> Chad Knepp
> python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'
> _______________________________________________
> pcplantdb mailing list
> pcplantdb@lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/pcplantdb
>

---

Whatever you Wanadoo

This email has been checked for most known viruses - find out more here