Pascal Georges wrote:
Hi!
> It is to be asked if the array of flags could be extended a
> bit. That is, that there could be more flags without
> breaking any compatibility. (E.g. personally I'd like to
> have more user flags.)
> This is not possible. There are only 16 flags.
I hoped you say: this is easily extensible to 32, 64...
> Build it into scid: well this is the way arround using
> UIDs for categories and keywords. Not a flexible way but
> a doable way. I'd suggest to read them in from a file,
> though. That way every contributor could add a new term
> if (s)he feels necessary without touching program code.
>
> I prefer predefined categories, even the list can be increased from to
> time. If you let this "user defined", you will get :
> - tactics
> - tactic
> - tactical shot
> - taktik
Thats why I all the time vote for normalised material. ;)
Actually, as a librarian you'd set up a thesaurus to resolve
all this to the normalised term.
> for the same category. Then searches are impossible. This is a
> caricatural example, but the problem is there.
No it's real life if you have synonyms, not to speak of
translations in foreighn languages. But: A normalised list
does not have to be contained within the source it can be
read in like the spell checking file...
> 4. UID
[...]
> <basename>:<gameversion>-<number>
>
>
> PGN tags are handled as strings. With this layout, each game will have
> an UID which will cost around 20 chars. So the sg3 file is increased by
> 60 MB for a 3 M games DB. So the average number of games in each block
> will decrease, leading to an overall search penalty (more I/O). Note
> that events, white and black players tags for example are stored as
> references in the file sn3, because there are some repetitions. Of
> course UID does not repeat ...
Up to the bare number it does. But I see your point
nevertheless. You'd prefer a bare number to store it as an
integer? Eg. something like 3 digits for the version 12
digits for the indivitual number just concatenated and
filled by 0 up to 12 digits all the time, resulting in a 15
digits bare number. Would this be more efficient? Ie. if one
translates
CentriScid:12-12345678
as
012000012345678
stored as 12000012345678.
This does not work out for PGN headers. Did I get that
right? BTW: the multiple fields you suggested, wouldn't
they produce a much larger overhead? (It's a serious
question.) Actually, I thought I could reduce that by using
a single string.
> From a DB point of view, the key to find a game is for
> example the tuple (white, black, date, round). You
> propose a UID that acts as a "primary key" or "index" if
> you refer to the RDBMS point of view (DB2, ORACLE).
Sure, a primary key. I always think of a real DB. Maybe
thats a fault with scid.
> But the queries are not the same in Scid, so this key is
> not strictly necessary (there are no joint queries).
It is necessary to get a unique answer to a posed question.
The query in question would be "give me THIS game".
> Moreover I prefer the reference "Spassky Fischer 1972,
> round 3" than "game my_huge_ref_db:v12-12345678", because
> if I copy a game from a base to another "Spassky Fischer
> 1972, round 3" is still valid. Not "game
> my_huge_ref_db:v12-12345678".
You prefer this as you look at it as a human. You use your
intellect to check whether this is the correct game. You'll
even resolve "Spassky, B. Fischer R. 1972:3" correclty. If
I've set up another db and want to refer to it I've quite
some trouble with that. (The "other db" is not necessarily a
scid db.)
> And :
> - as a human, I prefer "Spassky Fischer 1972, round 3"
> - as a computer, I don't need the UID.
How do you nail it down uniquely? EXACTLY this game, "I need
a result set of exatly size 1 or 0". Actually, I need this in
CC, therefore there I introduced such a primary key.
(Simplified, it does not use versioning.)
[...]
> We can already easily import one DB into another with Scid, (CTRL D +
> drag and drop). The distribution of diff is trivial.
The point is not the import but the creation of the diff.
> I suggest to create this large reference DB with a strong
> focus on quality concerning header tags (what I call
> metadata), completeness with regards to tournaments and
> events, move orders as far as this is possible. I'd place
> "as big as possible" not as the primary target, but "as
> reliable as possible".
> Ok, I don't want to be negative, but where is the start of such DB ?
There're some tournaments that are readily available. I
also heard one voice or the other who would like to take it
up.
> [...]
>
> Still its up to the community to decide whether the
> V:12 and the V:17 version of the game in question is
> kept.
>
>
> I don't believe in a real "community" process here. For example look at
> contributions at
>
> http://www.chesspositiontrainer.com/English/Downloads/FreeChessRepertoires.aspx
>
> Each repertoire is made by a sole person, and nobody never gives
> feedback if he finds an improvement or enhances the repertoire. That's life.
This could happen as well. I can not judge it. (Hey, you
tell us right now that Web2 is pure non-sense. And I thought
I'm the only one on the planet who recognises that ;)
> I'd make CentriScid open to new tags added by the
> community of users that are not actively working on
> CentriScid. But this _requires_ to have UIDs for you to
> know at exactly which game to add infos provided from
> outside.
> This is not absolutely necessary. You can precisely designate a game by
> the tuple described above. If not, the DB is of poor quality.
I always think that I want to designate it by some software.
I see that I've no good stand with you in that point ;)
[...]
> This is ok in theory. But I'd prefer to put my hands on something
> concrete just to get some reality behind all that.
Creating stage 1 is pretty simple I guess. For stage 2 to 3
its more difficult, but there were one or two on the list
who wanted to start this.
NOTE: I _only_ made some suggestions how I'd think to build
up such things, partly from experiences I've with this
little paper things we store on shelves. Nobody has to care
about my suggestions or probably there're better solutions.
--
Kind regards, / War is Peace.
| Freedom is Slavery.
Alexander Wagner | Ignorance is Strength.
|
| Theory : G. Orwell, "1984"
/ In practice: USA, since 2001
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Scid-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/scid-users
