Loading ...
Sorry, an error occurred while loading the content.

Re: initial draft

Expand Messages
  • F. X. Flinn
    I have reviewed the excellent work of the DB design committee and have some suggestions: On Managers: Revisit the relationship of TeamsHalf and ManagersHalf
    Message 1 of 11 , Feb 1, 2003
    • 0 Attachment
      I have reviewed the excellent work of the DB design committee and have
      some suggestions:

      On Managers:

      Revisit the relationship of TeamsHalf and ManagersHalf tables as given
      in the Relationships screen in the shell. I don't think it should tie to
      ManagersID in Master. Master should not need a ManagersID field; instead
      the Managers table should have a PlayerID field which is populated if
      the Manager was a player and has an entry in the Master table.

      MASTER

      Recommend adding Fields

      APName: Player's name as given in AP Wire Service data
      USATodayName: Player's name as given in USA Today online data
      ShandName: Player's name as given in Ron Shandler's BaseballHQ
      output
      USATodayID: USA Today ID number as found in hyperlinks
      MLBID: MLB ID number as found in hyperlinks
      CemetaryID: This field will let us track where the player is
      interred.
      CemetaryLoc: This would be the cemetary's internal coding, eg
      C45R02.
      PlayerURL: if the player has his own website....
      SABRID: player ID from HR Log & Bibliography tables

      These fields will make matching with online resources a lot
      easier. I have extensive cross-referenced tables of this sort.

      Birth Location Information:

      Instead of birthCountryID, StateID and unlinked City:

      birthLocationID --> LocationID in Locations
      deathLocationID --> LocationID in Locations

      New tables:

      LOCATIONS (get rid of States and Cities)

      LocationID: Key
      City: Current Name of City or locality
      State: Current Name of State or region
      Country: Current Name of Nation
      PostalCode: Current Postal Code
      PriorID: Location prior to change to Current Name
      NextID: Location after a change
      Active: Boolean - is this naming still used

      Ideally Locations will allow future researchers to use mapping
      technology to generate interesting player geographic studies. Also it
      will simplify tracking international players across country name changes
      and the like. Standard Location databases are widely available.

      Locations can also be used for Colleges and Parks

      CEMETARIES

      CemetaryID
      Name
      StreetAddress
      LocationID
      Phone
      Website
      ContactName
      Email


      IMAGES

      PlayerID
      Image
      Description
      Year
      Photographer
      CopyrightHolder

      Teams and Franchises need some more work. Here are my incomplete ideas,
      largely based on what I find in David Vincent's work in the HR Log
      database.

      TeamList

      LocationID, which will give HomeCity.

      Alias needs a more careful definition, or better, several
      different fields (using 2002 Yanks as example). The main thing here is
      to allow for flexibility in matching team codes as used by different
      sources:

      TeamID:
      FranchID:
      PlaceName: New York
      NickName: Yankees
      Alias: Yanks
      AllAliases: Yanks, Bombers, Bronx Bombers
      AllCodes: NYY, NYA
      MLBTeam: NYA
      APTeam: NYY
      USATeam: NYA
      Active

      FRANCHISES (example, Braves, 4 records)

      FranchID: BS1, BSN, MLN, ATL
      FranchCode: BS1, BS1, BS1, BS1
      Sequence: 1, 2, 3, 4
      LeagueID: NA, NL, NL, NL
      StartDate:
      EndDate:
      StartYear:
      EndYear: 1875, 1952, 1965, 0
      Active: N, N, N, Y

      That's about all the thoughts I have right now on this sad day.

      F. X. Flinn
      802-295-9362
    • Derek Adair
      A number of the suggestions below make a lot of sense. I like the locations suggestion, in particular. A couple of thoughts: I don t understand the rationale
      Message 2 of 11 , Feb 1, 2003
      • 0 Attachment
        A number of the suggestions below make a lot of sense. I like the
        locations suggestion, in particular. A couple of thoughts:

        I don't understand the rationale that Master doesn't need a ManagersID
        field. Master is a listing of all of the "people" in the database, not
        just players. So getting rid of the link except where a manager has played
        doesn't seem to be the course to follow. I might be misunderstanding here,
        though.

        I'm in favor of some of the ID additions. The MLB player code addition is
        one I have the data for; that should be in Master soon. I'm not completely
        sold on entries like "ShandName." Maybe that's because I don't visit
        BaseballHQ much at all, so I don't have a good grasp on the usefulness of
        that entry.

        PlayerURL is another one I'm unsure about - that adds a large maintenance
        burden. Maybe that's worth it as well; I'd be interested in others'
        opinions here.

        SABRID - No clue what SABR uses to ID their players. What's the scheme?
        It's disheartening that there's yet another ID scheme out there, but it
        comes with the territory, I guess.

        Finally, and this is small, but I wanted to make note of it before any
        related work got submitted - "cemetery" is the correct spelling.

        Regards,
        Derek Adair
        dadair@...

        On Sat, 1 Feb 2003, F. X. Flinn wrote:

        >
        >
        > I have reviewed the excellent work of the DB design committee and have
        > some suggestions:
        >
        > On Managers:
        >
        > Revisit the relationship of TeamsHalf and ManagersHalf tables as given
        > in the Relationships screen in the shell. I don't think it should tie to
        > ManagersID in Master. Master should not need a ManagersID field; instead
        > the Managers table should have a PlayerID field which is populated if
        > the Manager was a player and has an entry in the Master table.
        >
        > MASTER
        >
        > Recommend adding Fields
        >
        > APName: Player's name as given in AP Wire Service data
        > USATodayName: Player's name as given in USA Today online data
        > ShandName: Player's name as given in Ron Shandler's BaseballHQ
        > output
        > USATodayID: USA Today ID number as found in hyperlinks
        > MLBID: MLB ID number as found in hyperlinks
        > CemetaryID: This field will let us track where the player is
        > interred.
        > CemetaryLoc: This would be the cemetary's internal coding, eg
        > C45R02.
        > PlayerURL: if the player has his own website....
        > SABRID: player ID from HR Log & Bibliography tables
        >
        > These fields will make matching with online resources a lot
        > easier. I have extensive cross-referenced tables of this sort.
        >
        > Birth Location Information:
        >
        > Instead of birthCountryID, StateID and unlinked City:
        >
        > birthLocationID --> LocationID in Locations
        > deathLocationID --> LocationID in Locations
        >
        > New tables:
        >
        > LOCATIONS (get rid of States and Cities)
        >
        > LocationID: Key
        > City: Current Name of City or locality
        > State: Current Name of State or region
        > Country: Current Name of Nation
        > PostalCode: Current Postal Code
        > PriorID: Location prior to change to Current Name
        > NextID: Location after a change
        > Active: Boolean - is this naming still used
        >
        > Ideally Locations will allow future researchers to use mapping
        > technology to generate interesting player geographic studies. Also it
        > will simplify tracking international players across country name changes
        > and the like. Standard Location databases are widely available.
        >
        > Locations can also be used for Colleges and Parks
        >
        > CEMETARIES
        >
        > CemetaryID
        > Name
        > StreetAddress
        > LocationID
        > Phone
        > Website
        > ContactName
        > Email
        >
        >
        > IMAGES
        >
        > PlayerID
        > Image
        > Description
        > Year
        > Photographer
        > CopyrightHolder
        >
        > Teams and Franchises need some more work. Here are my incomplete ideas,
        > largely based on what I find in David Vincent's work in the HR Log
        > database.
        >
        > TeamList
        >
        > LocationID, which will give HomeCity.
        >
        > Alias needs a more careful definition, or better, several
        > different fields (using 2002 Yanks as example). The main thing here is
        > to allow for flexibility in matching team codes as used by different
        > sources:
        >
        > TeamID:
        > FranchID:
        > PlaceName: New York
        > NickName: Yankees
        > Alias: Yanks
        > AllAliases: Yanks, Bombers, Bronx Bombers
        > AllCodes: NYY, NYA
        > MLBTeam: NYA
        > APTeam: NYY
        > USATeam: NYA
        > Active
        >
        > FRANCHISES (example, Braves, 4 records)
        >
        > FranchID: BS1, BSN, MLN, ATL
        > FranchCode: BS1, BS1, BS1, BS1
        > Sequence: 1, 2, 3, 4
        > LeagueID: NA, NL, NL, NL
        > StartDate:
        > EndDate:
        > StartYear:
        > EndYear: 1875, 1952, 1965, 0
        > Active: N, N, N, Y
        >
        > That's about all the thoughts I have right now on this sad day.
        >
        > F. X. Flinn
        > 802-295-9362
      • Paul Wendt
        ... SABR Membership IDs, I presume. Some baseball personages are SABR members or former members. Eg, minor player Art Johnson. Eg, major player and manager
        Message 3 of 11 , Feb 1, 2003
        • 0 Attachment
          1 Feb 2003, Derek Adair wrote:

          > SABRID - No clue what SABR uses to ID their players. What's the scheme?
          > It's disheartening that there's yet another ID scheme out there, but it
          > comes with the territory, I guess.

          SABR Membership IDs, I presume.
          Some baseball personages are SABR members or former members.

          Eg, minor player Art Johnson.
          Eg, major player and manager Larry Dierker.
          Indeed, guest participants in the Annual Convention get complimentary
          one-year memberships. Bud Selig 2001. Pesky & DiMaggio 2002.

          --Paul
        • Derek Adair
          ... What I meant by the above was that I didn t know what the scheme was to create the ID s (such as first five letters of the last name, first two of the
          Message 4 of 11 , Feb 1, 2003
          • 0 Attachment
            On Sat, 1 Feb 2003, Paul Wendt wrote:

            > 1 Feb 2003, Derek Adair wrote:
            >
            > > SABRID - No clue what SABR uses to ID their players. What's the scheme?
            > > It's disheartening that there's yet another ID scheme out there, but it
            > > comes with the territory, I guess.
            >
            > SABR Membership IDs, I presume.
            > Some baseball personages are SABR members or former members.
            >
            > Eg, minor player Art Johnson.
            > Eg, major player and manager Larry Dierker.
            > Indeed, guest participants in the Annual Convention get complimentary
            > one-year memberships. Bud Selig 2001. Pesky & DiMaggio 2002.

            F.X. was referring to these:

            > SABRID: player ID from HR Log & Bibliography tables

            What I meant by the above was that I didn't know what the scheme was to
            create the ID's (such as first five letters of the last name, first two of
            the first name, plus a number).

            Regards,
            Derek
          • F. X. Flinn
            The SABRID is the numeric PlayerID in the Bibliography committee players table and is used extensively in the HRLog. I have a well developed table that cross
            Message 5 of 11 , Feb 1, 2003
            • 0 Attachment

              The SABRID is the numeric PlayerID in the Bibliography committee players table and is used extensively in the HRLog.

               

              I have a well developed table that cross references it with Retro, Lahman, etc.

               

              A numeric ID is a must for the long haul. I appreciate the Lahman and Retro schemes, but you can’t beat an integer for performance.

               

              If the Master table is going to list everyone as opposed to only players, something I didn’t appreciate, it needs to have an independent key and a separate type field, then extra IDs for connectivity to other tables. As a matter of fact, a PersonID and type field would suffice if there were various separate “rosetta” tables, like the PlayerCodeRosetta:

               

              PersonID -> LahmanID, Retro, HRLog, etc

               

              To query player stats you’d link to the rosetta, get the Lahman key, and query the stats.

               

              To query a player’s HR’s you’d link to the rosetta, get the HRLog key, and query the log

               

              Other people – Like scouts or managers or owners – would be handled with other rosetta tables:

               

              PersonID - > ManagerID

               

              To query Manager info, you link to that and then hit the Managers data tables.

               

              On Maintenance:

               

              Obviously the master bibliographic table will have to have some kind of central maintanence. SABR will take this on as it has always ultimately been the resource these types of lists have started with. Most player biographical data floating around is based on the work of the Biographical committee anyway. SABR has the resources and organizational commitment to see this through. This table will be freely available for download in multiple formats.

               

               

              FXF

               

              -----Original Message-----
              From: Derek Adair [mailto:dadair@...]
              Sent:
              Saturday, February 01, 2003 5:41 PM
              To: baseball-databank@yahoogroups.com
              Subject: Re: [baseball-databank] Re: initial draft

               

              A number of the suggestions below make a lot of sense. I like the
              locations suggestion, in particular. A couple of thoughts:

              I don't understand the rationale that Master doesn't need a ManagersID
              field. Master is a listing of all of the "people" in the database, not
              just players. So getting rid of the link except where a manager has played
              doesn't seem to be the course to follow. I might be misunderstanding here,
              though.

              I'm in favor of some of the ID additions. The MLB player code addition is
              one I have the data for; that should be in Master soon. I'm not completely
              sold on entries like "ShandName." Maybe that's because I don't visit
              BaseballHQ much at all, so I don't have a good grasp on the usefulness of
              that entry.

              PlayerURL is another one I'm unsure about - that adds a large maintenance
              burden. Maybe that's worth it as well; I'd be interested in others'
              opinions here.

              SABRID - No clue what SABR uses to ID their players. What's the scheme?
              It's disheartening that there's yet another ID scheme out there, but it
              comes with the territory, I guess.

              Finally, and this is small, but I wanted to make note of it before any
              related work got submitted - "cemetery" is the correct spelling.

              Regards,
              Derek Adair
              dadair@...

              On Sat, 1 Feb 2003, F. X. Flinn wrote:

              >
              >
              > I have reviewed the excellent work of the DB design committee and have
              > some suggestions:
              >
              > On Managers:
              >
              > Revisit the relationship of TeamsHalf and ManagersHalf tables as given
              > in the Relationships screen in the shell. I don't think it should tie to
              > ManagersID in Master. Master should not need a ManagersID field; instead
              > the Managers table should have a PlayerID field which is populated if
              > the Manager was a player and has an entry in the Master table.
              >
              > MASTER
              >
              > Recommend adding Fields
              >
              >       APName: Player's name as given in AP Wire Service data
              >       USATodayName: Player's name as given in USA Today online data
              >       ShandName: Player's name as given in Ron Shandler's BaseballHQ
              > output
              >       USATodayID: USA Today ID number as found in hyperlinks
              >       MLBID: MLB ID number as found in hyperlinks
              >       CemetaryID: This field will let us track where the player is
              > interred.
              >       CemetaryLoc: This would be the cemetary's internal coding, eg
              > C45R02.
              >       PlayerURL: if the player has his own website....
              >       SABRID: player ID from HR Log & Bibliography tables
              >
              >       These fields will make matching with online resources a lot
              > easier. I have extensive cross-referenced tables of this sort.
              >
              > Birth Location Information:
              >
              >       Instead of birthCountryID, StateID and unlinked City:
              >
              >       birthLocationID --> LocationID in Locations
              >       deathLocationID --> LocationID in Locations
              >
              > New tables:
              >
              > LOCATIONS (get rid of States and Cities)
              >
              >       LocationID: Key
              >       City: Current Name of City or locality
              >       State: Current Name of State or region
              >       Country: Current Name of Nation
              >       PostalCode: Current Postal Code
              >       PriorID: Location prior to change to Current Name
              >       NextID: Location after a change
              >       Active: Boolean - is this naming still used
              >
              >       Ideally Locations will allow future researchers to use mapping
              > technology to generate interesting player geographic studies. Also it
              > will simplify tracking international players across country name changes
              > and the like. Standard Location databases are widely available.
              >
              >       Locations can also be used for Colleges and Parks
              >
              > CEMETARIES
              >
              >       CemetaryID
              >       Name
              >       StreetAddress
              >       LocationID
              >       Phone
              >       Website
              >       ContactName
              >       Email
              >
              >
              > IMAGES
              >
              >       PlayerID
              >       Image
              >       Description
              >       Year
              >       Photographer
              >       CopyrightHolder
              >
              > Teams and Franchises need some more work. Here are my incomplete ideas,
              > largely based on what I find in David Vincent's work in the HR Log
              > database.
              >
              > TeamList
              >
              >       LocationID, which will give HomeCity.
              >
              >       Alias needs a more careful definition, or better, several
              > different fields (using 2002 Yanks as example). The main thing here is
              > to allow for flexibility in matching team codes as used by different
              > sources:
              >
              >       TeamID:
              >       FranchID:
              >       PlaceName: New York
              >       NickName: Yankees
              >       Alias: Yanks
              >       AllAliases: Yanks, Bombers, Bronx Bombers
              >       AllCodes: NYY, NYA
              >       MLBTeam: NYA
              >       APTeam: NYY
              >       USATeam: NYA
              >       Active
              >
              > FRANCHISES (example, Braves, 4 records)
              >
              >       FranchID: BS1, BSN, MLN, ATL
              >       FranchCode: BS1, BS1, BS1, BS1
              >       Sequence: 1, 2, 3, 4
              >       LeagueID: NA, NL, NL, NL
              >       StartDate:
              >       EndDate:
              >       StartYear:
              >       EndYear: 1875, 1952, 1965, 0
              >       Active:      N, N, N, Y
              >
              > That's about all the thoughts I have right now on this sad day.
              >
              > F. X. Flinn
              > 802-295-9362

              http://www.baseball-databank.org/

              To unsubscribe from this group, send an email to:
              baseball-databank-unsubscribe@yahoogroups.com



              Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

            • Paul Wendt
              ... I believe David Vincent maintains a cross reference table as the Biographical Database adds new persons. --Paul
              Message 6 of 11 , Feb 1, 2003
              • 0 Attachment
                1 Feb 2003, F. X. Flinn wrote:

                > I have a well developed table that cross references it with Retro,

                I believe David Vincent maintains a cross reference table as the
                Biographical Database adds new persons.

                --Paul
              • F. X. Flinn
                Right. Same thing. ... From: Paul Wendt [mailto:pgw@world.std.com] Sent: Saturday, February 01, 2003 6:26 PM To: baseball-databank@yahoogroups.com Subject: RE:
                Message 7 of 11 , Feb 1, 2003
                • 0 Attachment

                  Right. Same thing.

                   

                  -----Original Message-----
                  From: Paul Wendt [mailto:pgw@...]
                  Sent: Saturday, February 01, 2003 6:26 PM
                  To: baseball-databank@yahoogroups.com
                  Subject: RE: [baseball-databank] Re: initial draft

                   

                  1 Feb 2003, F. X. Flinn wrote:

                  > I have a well developed table that cross references it with Retro,

                  I believe David Vincent maintains a cross reference table as the
                  Biographical Database adds new persons.

                  --Paul


                  http://www.baseball-databank.org/

                  To unsubscribe from this group, send an email to:
                  baseball-databank-unsubscribe@yahoogroups.com



                  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

                • Derek Adair
                  ... If you could send that my way, I d be happy to merge that with the Master table. ... See below. ... It does have an independent key if you examine the
                  Message 8 of 11 , Feb 1, 2003
                  • 0 Attachment
                    On Sat, 1 Feb 2003, F. X. Flinn wrote:

                    > The SABRID is the numeric PlayerID in the Bibliography committee players
                    > table and is used extensively in the HRLog.
                    >
                    >
                    >
                    > I have a well developed table that cross references it with Retro,
                    > Lahman, etc.

                    If you could send that my way, I'd be happy to merge that with the Master
                    table.

                    > A numeric ID is a must for the long haul. I appreciate the Lahman and
                    > Retro schemes, but you can't beat an integer for performance.

                    See below.

                    > If the Master table is going to list everyone as opposed to only
                    > players, something I didn't appreciate, it needs to have an independent
                    > key and a separate type field, then extra IDs for connectivity to other
                    > tables. As a matter of fact, a PersonID and type field would suffice if
                    > there were various separate "rosetta" tables, like the
                    > PlayerCodeRosetta:

                    It does have an "independent key" if you examine the sql version, as
                    opposed to the bare text:

                    > lahmanID int(9) NOT NULL auto_increment,

                    and it does have those other ID's you mention. The old LahmanID (5,2,##)
                    is now PlayerID and the manager, etc. ID's are variations on that scheme.

                    The decision was made to go this route instead of having multiple tables
                    to reduce the number of joins (and because there wasn't a real need for
                    keeping the tables separate).

                    > On Maintenance:
                    >
                    >
                    >
                    > Obviously the master bibliographic table will have to have some kind of
                    > central maintanence. SABR will take this on as it has always ultimately
                    > been the resource these types of lists have started with. Most player
                    > biographical data floating around is based on the work of the
                    > Biographical committee anyway. SABR has the resources and organizational
                    > commitment to see this through. This table will be freely available for
                    > download in multiple formats.

                    We'll see. I'd be quite happy if the resources flowed through there as
                    freely as you mention, but I think we're a long way from relying on SABR
                    for that information. We definitely should not duplicate the effort, but
                    we shouldn't leave ourselves in a position where we're high-and-dry if a
                    different SABR administration with different politics comes along.

                    Regards,
                    Derek
                  • Paul Wendt
                    ... I have a single-table view of the Biographical Database covering all and only the 1871 players. This is not much help to Derek but for the incomplete
                    Message 9 of 11 , Feb 1, 2003
                    • 0 Attachment
                      1 Feb 2003, Derek Adair wrote:

                      > F.X. was referring to these:
                      >
                      > > SABRID: player ID from HR Log & Bibliography tables
                      >
                      > What I meant by the above was that I didn't know what the scheme was
                      > to create the ID's (such as first five letters of the last name, first
                      > two of the first name, plus a number).
                      >
                      > Regards,
                      > Derek

                      I have a single-table view of the Biographical Database covering all
                      and only the 1871 players. This is not much help to Derek but for
                      the incomplete general education of others, the scheme is 4-1-3.

                      ham-r101 Ralph Ham
                      hasts101 Scott Hastings

                      None of the 1871 surnames includes an apostrophe.

                      --Paul
                    • tmasc@yahoo.com
                      Thanks for your comments. See my comments that are interspersed, and those that I have no comments to, I have snipped off.... ... Please note that what we did
                      Message 10 of 11 , Feb 1, 2003
                      • 0 Attachment
                        Thanks for your comments. See my comments that are
                        interspersed, and those that I have no comments to, I
                        have snipped off....

                        --- "F. X. Flinn" <F.X.Flinn@...> wrote:
                        > On Managers:
                        >
                        >Master should not need a
                        > ManagersID field; instead
                        > the Managers table should have a PlayerID field
                        > which is populated if
                        > the Manager was a player and has an entry in the
                        > Master table.
                        >

                        Please note that what we did with managersID,
                        umpiresID, etc, etc is that sometimes we don't know if
                        the manager/player was the same guy, and we have
                        different people compiling different lists. So, what
                        we had decided last year was that each class of people
                        gets its own field, and then, if we can, or when we
                        can, we link them, *without* afterwards renaming any
                        of the ID values. This seemed a good idea at the
                        time, but maybe in the future we'll change it.


                        > MASTER
                        >
                        > Recommend adding Fields
                        >

                        Anyone who wants to add any data, we'll gladly xref to
                        it. I think the design is extensible in that way.
                        Heck, I'd like to get the ESPN playerID's so that
                        maybe Sean can link to it easily at b-r.com, like he
                        does with Retrosheet and baseball-alamanac, etc.

                        > LOCATIONS (get rid of States and Cities)

                        You always need state, because you can't have a value
                        like YZ.

                        I'll look into your suggestions on Monday.

                        >
                        > CEMETARIES
                        >
                        > CemetaryID
                        > Name
                        > StreetAddress
                        > LocationID
                        > Phone
                        > Website
                        > ContactName
                        > Email
                        >
                        >

                        Same as earlier. If someone has the data, I'd gladly
                        extend it to include any data.

                        > IMAGES
                        >
                        > PlayerID
                        > Image
                        > Description
                        > Year
                        > Photographer
                        > CopyrightHolder
                        >

                        This would actually be great. I never thought about
                        it. Again, if we have data, we can extend it.

                        > Teams and Franchises need some more work.

                        Let's wait for the Franchise committee to report, and
                        let's review what you listed. It looks like you have
                        multiple franchises for the same ballclub. I'm not
                        sure I read it right. In any case, let's tackle this
                        in a couple of weeks.

                        Thanks much for the comments.

                        Thanks, Tom

                        __________________________________________________
                        Do you Yahoo!?
                        Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
                        http://mailplus.yahoo.com
                      • Paul Wendt
                        ... Even for AL1900, the best known of old minor leagues, there are several players whose identity with some MLB player is guessed, but not secured. (Eg, Which
                        Message 11 of 11 , Feb 2, 2003
                        • 0 Attachment
                          1 Feb 2003, tmasc@... wrote:

                          > Please note that what we did with managersID, umpiresID, etc, etc is
                          > that sometimes we don't know if the manager/player was the same guy,
                          > and we have different people compiling different lists. So, what we
                          > had decided last year was that each class of people gets its own
                          > field, and then, if we can, or when we can, we link them, *without*
                          > afterwards renaming any of the ID values. This seemed a good idea at
                          > the time, but maybe in the future we'll change it.

                          Even for AL1900, the best known of old minor leagues, there are several
                          players whose identity with some MLB player is guessed, but not secured.
                          (Eg, Which Jack Ryan is that?)
                          So IDs for subclasses of persons are valuable, maybe crucial.

                          --Paul
                        Your message has been successfully submitted and would be delivered to recipients shortly.