Cory Helfrich wrote:
Hi!
>> **Unique Ids**. ~~ Those little gremlins are what makes
>> a database a real database. We should normalize to a
>> point we get those for all the essential parts of our
>> information system. All the work my friend is doing is
>> of absolutely no use because he prefers to trim down all
>> his information to a bare minimum : he's building his
>> repertoire, history is of no concern to him.
>
> I was hoping to keep all information intact (i.e., the
> seven-tag roster plus any other information present).
At least for me, I was just speaking about extending. Never
throw away anything. In case just normalise it (ie.
normalisation of names, events, sites, spellings etc.).
A unique id would just enable you to tell your friend: "Ah,
I know that line. Check out CentriScid-123456789" and he
could not go wrong. In library speak one would call it a
persistent identifier. They're really worth one thing or the
other. Imagine that for "CentriScid-123456789" you'd
otherwise probably need:
Mueller, Anton Michael vs. Werner, Hans-Martin, Zuerich
2005, round 7 game 2.
Additionally, you could implement the diff easily. You could
make a cut at ID... Changes in older IDs could be tracked
and one could uniquely extract those IDs to give out a diff.
>> **Possible solution**. ~~ The only reasonable idea, as far as my
>> one hour commuting reflexion led me, is to work it piecemeal. If
>> someone is working in some subset of games, his work could be
>> announced on the game or tournament list form I was alluding to
>> sooner today. (I don't know if Trac could do that, anyway, let's
>> speak theorically.) The person that is adding or correcting some
>> games send those to a repository. Each nighly (let's stay humble
>> and say monthly) build then merge all the games into one of the dev-
>> db.
>
> Good solution. Do you suggest keeping the subsets of games in pgn
> format?
>
> Let me tell you where I am coming from. I am not a programmer and
> have little experience with multiple users working on a common
> project, so "CVS" and similar terms are new to me. I do use scid and
> this has helped my chess learning immensely. I am looking for
> something I can do to contribute something useful. This appears to be
> something I can do. Just let me know how I can best contribute.
For the database and the opening book project I'd strongly
suggest to keep the technical profile as low as possible. I
would suggest to split the contributions on some "higer,
intellectual level" like "I'm working through TWIC 700-710,
and you can work in those older tournaments". I'd suggest to
leave it to each contributor how to organise that and just
set up one simple solution to combine all contributions into
the DB.
I think such a DB project would help many people, and it
would enable especially also non-programmers to contribute.
In the past, similar projects projects where accomplished
with paper an pencil, therefore I do not see a point in
rising technical problems here. I feel it more important
that it could address a larger community. I'd suggest to
start small. If it grows and there arrises the need to
introduce some more advanced technical solution one could
still do it at that point. Then, all members would also have
some experience from the ongoing project, could state the
needs clearly and one could look for a proper solution. I've
the experience, that to high technical barriers just scare
away people that otherwise would join in. I'd prefer to see
this avoided. Point is: first build the community and if it
is so large that some technology is necesary, _then_ think
about technology. I saw many good projects die as they
thought about the technology before the community and most
manpower went into technology instead of the project.
Besides: I'm not sure that cvs or a similar tool is suitable
for a project that would result in that large an ammount of
individual files if you keep it in pgn. Surely, it can
handle it but I don't think very effectively.
Maybe it is a better idea to select one of the contributors
to put individually created scid-dbs together at certain
stages.
In any rate: one of the first things the community has to do
is to set up some ideas how the game tags are handled, which
tags are necessary, which are nice to have how to normalise
them, if and how to add a unique id, how sources should be
named (e.g. is it "The Pitsburg Chess Archive" or "Pitsburg
Chess Archives" or "Pitsburg Chess Archive, The" ...) You do
not need to invent a whole complete set of detailed rules,
I'd keep it on the "best practise level". And to stick with
the example: if it's decided how to call that beast, just
add it at the end of this "manual" for easy lookup by all
contributors. This list has low enough traffic that it
could easily handle the posting of such a document from time
to time. If need be one could move on to a more advanced
solution later on.
I think this has to be written down for easy reference. I
suggest to start this as a thread here on the list. As far
as I can currently see Cory and Israel are interested in the
project as well as Benoit but he said that he could not
actively contribute to much personally. Concerning stuff
like handling of tags or something the like I might
contribute some ideas from my job as well.
--
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
