[Babase] Re: MPI Data cleanup
Karl O. Pinc
kop at meme.com
Wed Nov 25 12:41:58 EST 2009
On 11/25/2009 11:28:25 AM, Lacey Maryott Roerish wrote:
> As it now exists... if the outcome is PASS, there will be no
> subsequent line
> indicating XXX P YYY
> if the outcome is SUCC, there will be a subsequent line that says XXX
> + YYY
> there will NOT be a subseqent line saying XXX AS ZZZ
> if the outcome is fail... there will be no subseqent, related line.
> There
> may be other information, but nothing about that particular request.
Makes sense to me.
>
> I realize that that isn't really standardized, and I'm not sure how
> much we
> should ask the upload program to 'reconstruct' aka, do we WANT a
> line
> created that says XXX AS ZZZ given that we have all of that
> information
> being input? Do we NOT want a line in the entry that says XXX+YYY,
> do we
> want the upload program to create it... do we want to leave it out
> altogether. I think that if the program could create lines like XXX
> P YYY,
> and XXX AS ZZZ from what it is given, that would be fantastic.. I'm
> just now
> sure how much redundancy we want and how clear it will all be in the
> DB with
> or without this information once in the database.
My inclination is to leave it out, and leave it to the researcher
to know that, e.g, a successful request results in an AS.
This is to avoid putting the "same information" into the
database in two different ways, and avoiding possible resultant
conflicts should the data mis-match. Alternately, we could
make validation rules, or at least warnings, that check.
At the moment I'd prefer to keep it simple -- although
simple is in the eye of the beholder here.
>
> Anyway, here it is
Thanks.
>
> L
>
> On Tue, Nov 24, 2009 at 5:34 PM, Karl O. Pinc <kop at meme.com> wrote:
>
> > On 11/24/2009 03:46:29 PM, Lacey Maryott Roerish wrote:
> > > I think I am pretty easily able to clean up the MPI data i am
> > > preparing to
> > > send Karl in the following ways...
> > >
> > > I can remove the following instances
> > > 1.
> > > SOR ? OCE P
> > > OCE P SOR
> > >
> > > Since the P between actor and actee is supposed to indicate
> > > unsolicited
> > > help, it does not belong directly after a help request answered
> with
> > > pass
> > > help, right?
> >
> > I suppose. Unless there's a second "help" that was not solicited.
> > I don't really know the protocol so I can't say.
> >
> > >
> > > 2.
> > > SOR P OCE P
> > > OXY P OCE P
> > >
> > > Since the initial act is not a request for help, there should be
> no
> > > 'outcome' or passive, etc, it seems like it is just accidental,
> > > redundant
> > > information
> >
> > The 2nd P on each line seems redundant. Because the line is not
> > a request for help the second P is not legal, there's no where to
> > put it.
> >
> > >
> > > These are the most obvious ones right now... I'm sorry that this
> file
> > > needed
> > > more cleanup that I initially thought. I have had the file
> proofed
> 3
> > > different times, looking for different errors like this, and for
> the
> > > error
> > > of having SUCC or + help reentered as an AS line.. trying to
> remove
> > > some
> > > of those redundancies..
> > >
> > > Anyway... Should this cleanup happen now, or during upload?
> >
> > Anything you catch now you won't have to do later.
> >
> >
> >
> > Karl <kop at meme.com>
> > Free Software: "You don't pay back, you pay forward."
> > -- Robert A. Heinlein
> >
> >
>
>
> --
> - -
> Lacey K. Maryott Roerish
> Alberts Lab
> Department of Biology
> Duke University
> ph: 919-660-7306
> fax: 919-660-7293
> Lacey.Maryott at duke.edu
>
Karl <kop at meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
More information about the Babase
mailing list