FREEBMD-SYNDICATES-L Archives

Archiver > FREEBMD-SYNDICATES > 2011-09 > 1315068537


From: Allan Raymond <>
Subject: Re: RE: Re: Superseded transcriptions - status
Date: Sat, 3 Sep 2011 17:48:57 +0100 (BST)


Barrie

The way I view this is that we should be attempting to get as accurate a transcription as possibly of the same index page but not necessarily from the same scan by two syndicates independent of one another (ignoring the complication caused by alternative handwritten and typed/printed scans)
 
The UCF report is identifying files which presumable because of poor scans were not able to be accurately transcribed. If this is the case then as part of double keying process it would be unrealistic to try and compare the transcriptions from the two independent syndicates involved in double keying since it is already recognised one of the files (i.e. the UCF file) is not accurate in its transcription.
 
If under your proposed suggestion we supersede a file by possibly one from another syndicate involved in double keying there is no way of carrying out a comparison of this superseding file against another quality transcribed file. This comparison can only be achieved if the UCF file is superseded by one transcribed from within the same syndicate. It may also be the case that the superseding file whilst not having any UCFs may have other transcription errors which hopefully are likely to picked up by comparison with another independently transcribed file.
 
Allan Raymond
 
  
 
 

--- On Thu, 1/9/11, Barrie Archer <> wrote:

> From: Barrie Archer <>
> Subject: Re: RE: Re: Superseded transcriptions - status
> To:
> Date: Thursday, 1 September, 2011, 10:02
> Allan,
>
> There is obviously a significant misunderstanding about
> superseded files which I
> am trying to get my mind round.
>
> Why would superseding a file with a file from another
> syndicate be contrary to
> the double keying process? All superseding a file really
> does is delete the file
> (except that it still gives credit to the transcriber).
> Plainly if a file is
> deleted (or superseded) it can no longer contribute to
> double keying but that is
> not "contrary to the process".
>
> The "link" between a superseded file and the file
> superseding it is only there
> to enable the credit to be given to the original
> transcriber. It does not imply
> anything about double keying.
>
> I could imagine, for example, that a syndicate transcribed
> a quarter which had a
> few bad scans. Later another syndicate transcribes these
> pages from better
> scans. The pages from the first syndicate would then be
> superseded with the
> files from the second syndicate.
>
> Another example might be that two syndicates have
> transcribed a page but the
> first was from such a bad scan that there is little
> meaningful information in
> the file, whereas the other transcription was "perfect". In
> such circumstances
> it would seem sensible to supersede the first transcription
> by the second to
> avoid presenting useless and confusing information to
> researchers.
>
> These examples may not be what will normally happen but I
> cannot see why they
> should be a problem.
>
> Regards
>
> Barrie
>
> On 19:59, Allan Raymond wrote:
> > Brian
> > 
> > I would hope any superseding files would be coming
> from the same syndicate and not from different syndicates
> involved in double keying. To do otherwise is contrary to
> the double keying process.
> > 
> > Allan Raymond
> >
> >
> > --- On Wed, 31/8/11, Brian Smart <>
> wrote:
> >
> >
> > From: Brian Smart <>
> > Subject: RE: Re: Superseded transcriptions - status
> > To:
> > Date: Wednesday, 31 August, 2011, 16:19
> >
> >
> > Hello Barrie,
> > I like the page which shows files that can be
> superseded by others but I do
> > NOT agree when the new files coming from another
> syndicate.
> > Each syndicate needs to have a complete set of
> acceptable files otherwise
> > how can the process of comparing files from two
> syndicates proceed?
> >
> > Where did the information re the superseded files come
> from as I don't
> > remember stating that the ones related to my syndicate
> were correct?
> >
> > Regards
> >
> > Brian Smart
> >
> >
> >
> >
> > -----Original Message-----
> > From:
> > [mailto:]
> On Behalf Of Barrie Archer
> > Sent: 30 August 2011 07:55
> > To:
> > Subject: Re: Re: Superseded transcriptions - status
> >
> > Please see http://www.freebmd.org.uk/UCFsuperseded.html which is
> basically
> > the
> > same as http://www.freebmd.org.uk/UCFusage.html but organised
> by syndicate
> > and
> > with possible superseded files listed against each
> file.
> >
> > The suggested files do need checking:
> >
> >     * occasionally the wrong file
> is suggested (where both files have
> > *,*,*,*,*
> >       records in them)
> >     * there are instances
> (hopefully rare) of transcribers just making up
> >       unreadable items rather
> than using UCF
> >
> >
> > At the next update this format will replace
> > http://www.freebmd.org.uk/UCFusage.html
> unless there are reasons to keep the
> > original.
> >
> > As an experiment I have also run the analysis for
> greater than 5% UCF - see
> > http://www.freebmd.org.uk/UCFsuperseded5.html which has
> approximately 5
> > times as
> > many primary files listed.
> >
> > Barrie
> >
> > On 19:59, Christopher Richards wrote:
> >> How big is the problem?  Would it be possible
> to automate this process.
> >>
> >> Say there are two transcriptions of a particular
> file.
> >>
> >> One has more than 10% uncertain characters. 
> The other has less than 1%.
> >>
> >> The  first file is then automatically put in
> the superseded list.
> >>
> >> This will deal with the worst cases but later the
> cut off may have to be
> > made
> >> more rigorous
> >>
> >> But even then I guess that the Syndicate
> Coordinator or the Volunteer
> >> Coodinator needs to do a manual check.
> >>
> >> I remember when checking files with a large number
> of uncertain characters
> > it
> >> was clear that some transcribers were better at
> reading Victorian
> > handwriting
> >> than others.
> >>
> >> Christopher Richards
> >>
> >> On 25/08/2011 09:58, Barrie wrote:
> >>> Brian,
> >>>
> >>> Currently there is an administrative file that
> contains a list of file
> >>> pairs, a superseded file and the file that
> supersedes it. One of the
> >>> questions that needs to be addressed is how
> superseded files get added
> >>> to this file or, indeed, whether some other
> interface is required.
> >>>
> >>> Where the file is in an active syndicate then
> I assume the Syndicate
> >>> Coordinator would make the decision. Otherwise
> it would be an
> >>> administrative coordinator, e.g. the Volunteer
> Coordinator.
> >>>
> >>> Regards
> >>>
> >>> Barrie
> >>>
> >>> On 19:59, Brian Smart wrote:
> >>>> Hello Barrie,
> >>>> How does a file get listed as superseded,
> who makes the decision?
> >>>> Regards
> >>>>
> >>>> Brian Smart
> >>>>
> >>>> -----Original Message-----
> >>>> From:
> >>>> [mailto:]
> On Behalf Of Barrie
> >>>> Sent: 23 August 2011 19:43
> >>>> To:
> >>>> Cc:
> >>>> Subject: Superseded transcriptions -
> status
> >>>>
> >>>> As a result of feedback on this facility I
> have made the following
> >>>> changes/investigations:
> >>>>
> >>>>      1. The wording has
> been changed as requested
> >>>>      2. I have checked that
> superseded files do not generate corrections
> >>>>     
>    emails and do not appear in the Suspect
> Files list
> >>>>      3. I have amended the
> UCF listing so it excludes superseded files
> >>>>      4. I have enhanced
> Upload Report so, whilst it does not list
> >>>>     
>    superseded files, there is a marker
> against any file that
> >>>>     
>    supersedes another file and this marker is
> a link to the
> >>>>     
>    superseded file
> >>>>      5. I have enhanced
> Show File so that it reports that a file is
> >>>>     
>    superseded when it is listed - and lists
> the file that supersedes
> > it
> >>>> Barrie

This thread: