On Thu, 2009-02-19 at 18:45 +0100, Alexander Wagner wrote:
Hi!
Interesting stuff, but you may have noticed that I am not the
fully-pack-it-with-features type of guy. I am more in favor of improving
what we have before adding new things (that may or may not be related,
even implementation-wise).
Furthermore, I do - as yet - not experience a sufficiently suitable
configuration management system (like trac/SVN, with multiple developers
branches and easy cross-merging, an (enfored) ticket system that allows
and implicitly documents changes, etc.) available to do anything else.
Making progress simply implies avoiding big bangs, by carefully
separating work packages. It does not smell like we have a huge
community to test our one-and-only CVS main line, so stability remains
key.
For me it is a nice "get into it" test to add the MaxCorrections option
stuff (although I still do not see what purpose this would serve, we can
remove it later anyway) and the progress bar in both use cases.
{For the record: I am an experienced software guy, who unfortunately
recently lost his job. So I can spend some time on scid-development, but
not more than my hopefully soon to be found next employer will allow me
to. Better start with something that I can finish for sure}
Other stuff for now remains in my inbox, but I guess the above portion
could be somehow released. Enhancements to the spell checking itself are
a next step.
Ok?
Now I will be off for the Bunratty chess weekend.
Cheers,
Joost.
> Joost ´t Hart wrote:
>
> Hello Joost!
>
> > I am willing to take this on, provided that we agree on
> > some sort of specification first.
>
> This is great news :)
>
> > So it is either
> > a) a configurable quicker scan, without knowing what is at
> > stake beyond,
> > or
> > b) a full scan, taking some time
>
> I prefer b) but this might be cause I admit that I can not
> understand the use of "correct only the first 1000
> misspelled names".
>
> > There is something to say for (a) as well.
> >
> > [Q] Do you a (all) agree that having a configurable
> > limitation implies approach (b) for "infinite" and (a) for
> > the other options?
>
> I would agree. Though as stated above personally I see no
> use in a limitation altogether.
>
> > [Q] Do you have any suggestions to enhance the hour glass
> > experience during the investigation phase?
> > A bar on the progress of the scan through the dBase name
> > list seems the most logical for approach (b), although it
> > will not necessarily reflect the time spent/to-go on
> > actually suggested corrections.
>
> Well, it seems logical and it seems consistent. IMHO it is
> also better than some %-bar that sticks for 99% of the time
> at 99% done.
>
> > [Q] So we add another configuration item somewhere in
> > "Options" or is there room for a "Config" button somewhere
> > in the maintenance dialog? I do not like the idea of
> > having an intermediate dialog each time (before the
> > investation is started).
>
> I might add, that it would be very helpful if I could have a
> set of spell checking files which can be switched there
> easily. Besides the FIDE names I've some other SSP-files for
> Club names e.g. Additionally, ICCF is work in progress. I
> have it on my personal basis, needs work for a release,
> though.
>
> Additionally, if you dive into the spell checking code you
> might notice, that ratings can be added to games that have
> none. However, the current code can only handle ELO, ie.
> FIDE ratings. That is, the current spell checker only
> evaluates the ELO lines in a ratings file and silently
> ignores other lines like ICCF. :(
>
> It would be great if the other rating systems supported by
> Scid (there are quite a bunch: ELO, ICCF, USCF, DWZ, BCF,
> Rating) could be added there as well. E.g. it makes not too
> much sense to add ELO ratings for a base of correspondence
> games rated by ICCF, there these values should go to ICCF
> field. (The aforementioned ICCF spell checking file is
> actually a rating file.) The same is true for Club games
> using the Clubs internal rating system, german players would
> probably like to add DWZ to the proper field and so on.
>
> As said, it's just about the interpretation of those lines
> in the rating file as such. A syntax for the rating file
> itself is already defined. I do not know if it is very much
> work to come here to a broader coverage.
>
> > [Q] What do you think of a producing a game list filter to
> > produce a list of games with inconsistent game date vs.
> > player life times?
>
> Sounds a good idea that could also help to find errors in a
> given database.
>
> > [Q] Dunno if you got the chance to notice this, but the
> > Chess Assistant guys follow the approach to explicitly add
> > a player's country (FIDE style) to the name in a pair of
> > ()'s. In the game list this country part is stripped off.
> > What do you think of this?
>
> I'd prefer some additional header fields like:
>
> [whiteCountry "HUN"]
> [blackCountry "EUR"]
>
> This would be more compatible to PGN standard as Pascal also
> pointed out.
>
> > It avoids quite some name conflicts, but certainly not
> > all.
>
> In the best of all worlds those additional fields would be
> used for checking, if present.
>
> > [Q] The CA guys have added a 'FIDE-id' field to the player database.
>
> This exists (or could exist) in the ratings files as well.
> Lines start by ID, the dataset can look like this:
>
> Aaldijk, A. A. # NED [2141]
> = Aaldijk, AA
> = Aaldijk, A
> %ID 370251 (ICCF)
> %ICCF 1996:1995 2000:2141 2000:2060,2017 2001:2004,1973
> 2002:1914,1921
> %ICCF 2003:1918,1918 2005:1866,1867 2006:1816,1813
>
> Notice, that at least ICCF and FIDE use identical schemes
> for their respecitve IDs, therefore a destinciton is needed.
> One could use the scheme suggested above, but also something
> like
>
> %ICCFID
> %ELOID
>
> etc. would make sense (ie. to link the ID with the rating
> system used). Probably, from our database point of view the
> latter is preferable.
>
> However, Franz told me that FIDE ID's are not unique in the
> sense that they are recycled. Therefore, one shouldn't rely
> to much on them, they probably make most sense together with
> the players lifespan only.
>
> > Looks nice for cross referencing with the improving FIDE
> > member lists (and we could add such id to the ssp as
> > well), but to my experience there are too many
> > (interesting) games played by players who do not even have
> > a FIDE id. Comments?
>
> It would not make sense to require an ID. Agree. Especially,
> you surely would not want to strip of the games of Aljekine
> etc ;)
>
> But adding the ID if it can be assinged IMHO adds additional
> value, indeed.
>
> > Would it imply a change to the existing dBase format, then
> > forget about it, imho.
>
> I'd hold those IDs again in additional header fields. For CC
> I currently use this kind of metadata:
>
> [Event "Welcome Game"]
> [Site "Internet Correspondence Chess Club"]
> [Date "2009.02.10"]
> [Round "?"]
> [White "whitename"]
> [Black "blackname"]
> [Result "*"]
> [WhiteRating "1234"]
> [BlackRating "1234"]
> [TimeControl "2592000+86400"]
> [GameId "123456"]
> [Source "http://www.iccc.com/game.aspx?game_id=123456";]
> [WhiteNA "wh...@unknown.org"]
> [BlackNA "bl...@unknown.org"]
> [Mode "XFCC"]
> [CmailGameName "ICCC-123456"]
> [whiteCountry "SRB"]
> [blackCountry "EUR"]
> [whiteIccfID "12345"]
> [blackIccfID "54321"]
>
> From a database point of view this is horrible, indeed, and
> one would surely replace e.g.
>
> [White "whitename"]
> [WhiteNA "wh...@unknown.org"]
> [whiteCountry "SRB"]
> [whiteIccfID "12345"]
>
> by just one unique ID that links to a proper normalised
> dataset, but this WOULD require to change the database'
> internal format. (Quite heavily, I might say.) However, it
> would have many advantages.
>
> However, the above has the charming aspect that it is
> perfecly compatible with PGN while adding quite a lot of
> additional and sometimes very valuable data to a games set
> of metadata.
>
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
