Skip to Content.
Sympa Menu

pcplantdb - [pcplantdb] Re: data/security model proposal

pcplantdb@lists.ibiblio.org

Subject: pcplantdb

List archive

Chronological Thread  
  • From: Chad Knepp <pyg@galatea.org>
  • To: pcplantdb@lists.ibiblio.org, piw@lists.ibiblio.org
  • Cc:
  • Subject: [pcplantdb] Re: data/security model proposal
  • Date: Mon, 21 Mar 2005 14:03:16 -0600

Richard Morris writes:
> Chad Knepp wrote:
> > Hello everyone,
> >
> > I have a new topic for discussion which is the data model (and its
> > security implications) for piw. Most of this I've discussed at
> > various times in smaller portions but here it is all together.
> >
> > The basic points:
> >
> > o All data in the dataset is owned by a user/author.
> >
> > o Users/authors can add/edit/delete objects.
> > The "PFAF/Ken Fern" elements will not be
> > editable unless some designated representative of PFAF desires to
> > do so.
>
> > I'm inclined to discourage write access to the PFAF/Ken Fern account
> > (see security implications).
> I'd agree here.
>
> I would allow a duplication and then edit.
> I.e. someone wants to change the pfaf text. To do that they create
> an copy of the pfaf text and add it as their own object. They can then
> edit the text at will. If the edits are good then the info
> will eventually be modded up until it better than pfaf data.

That would totally be an option under this model although direct
copying should credit the original source or violate the CC license
(internally?!? ...wierd).

> > o Writeable objects will be open to peer review/moderation which
> > will affect display priority.
>
> > o The core part of the plant object will be its botanical name.
> > This allows attachment of multiple descriptions, synonyms...
> >
> > o The elements of the current plant report that are titled Cultural
> > Notes, Propagation Notes, Known Hazards, Edible Uses, Medicinal
> > Uses, and Other Uses will become comments by PFAF attached to the
> > plant object (with a high score)
> >
> > o Registered user/authors (only) have the ability to moderate.
> >
> > Security implications:
> >
> > o Being a decentralized data model, an account compromise can at
> > worst cause a data loss of the contents of the data of that
> > specific user/author, and possibly spurious moderation.
> >
> Hopefully a backup system can be included at some point so we never
> loose data.

Yes, currently the database is static so periodic backups do not make
sense. This will be essential when it becomes dynamic in case of a
security compromise.

An additional advantage of this model is that purging or restoring any
given user will be very straight forward in the sense that they are
not intertwined in other data. Compromised/damaged accounts should be
easy to repair from a pre-compromise backup.

> > o Security is less critical with this model which means less than
> > best practice authentication methods are more acceptable such
> > as clear text transmission of authentication data.
> >
> > Anyway, think about it and let me know what y'all think.
> >
> > Cheers,
> > Chad
> >
> Great stuff. We really need to get this into whever our formal specs
> etc. goes.
>
> This model seems to have a stronger idea of ownership than say
> wikipedia, where the information is really a common, owned by no
> one. When people contribute to wikipedia the do so knowing that the data
> can and will be changed.

I think the proposed model makes more sense for data we are dealing
with. While history and the other sorts of more factual documentation
that takes place in wikipedia have a fairly objective scope, the
information we are dealing with is highly subjective and much of it
will just be user experience. Agreement on this user experience (via
moderation) will give display priority and allow the really good stuff
to be regarded as more factual.

> This has advantages that we can aproach authors who are
> understandable cautions about their IP and may be more likely to
> contribute.
>
> It may also make it easier for new people to contribute.
> I know from my experience of editing wikipedia is that
> its taken six months until I've felt confident enough to edit
> a page, it is quite a big responsibility to edit this data.
> However adding a comment is something a new user would feel
> easier about, less responsibility.

I think that the low barrier to user contribution in this model will
allow a higher level of total contribution.

> The disadvantage is that we'll end up with
> more fragmented data. There won't be the (current) definitive version of
> the dataset for a particular plant. Instead there will be
> a loose collection of datachunks.
>
> It does, I suspect, solve the locilisation problem.

Yes, as above, localization is one of the areas where the subjective
nature of the data we are dealing with is more evident. I actually
don't really know how localization fits yet in this model... possibly
a user definable filter similar to moderation.

> General feeling is its a bit complicated, but it could well work
> and it would be very interesting to see what happens.

I actually think this is the simplest model in terms of implementation
that I've thought of.

> Go for it.

Well, I want/need to have a bit/lot more discussion before calling for
consensus, but I'm glad you like ;-)

> Rich
>
> p.s. Seen a great movie of how a wikipedia page changes with time.
> Its one of the best things I've seen for understanding how this whole
> open content stuff can work and very convincing. Have a look at
> Heavy Metal Umlaut the movie
> http://weblog.infoworld.com/udell/gems/umlaut.html
> its well worth the download time.

'twas on slashdot a couple of days ago if I recall.

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




Archive powered by MHonArc 2.6.24.

Top of Page