Michal Rudolf wrote:
Hi!
Some sidenotes from the librarian as classification is part
of my job. ;)
>> So we should aim at a solution that relies more on
>> structure than feedback. A better idea for Scid would be
>> classify the exercises according to the kind of material
>> configuration : pawn structure and piece distribution.
> This makes sense for some special positional exercises and
> maybe for some endgame database. This isn't a general
> solution - for example, it doesn't help for tactics.
Well, in libraries you'd invent a classification sheme that
maps what is there and then assign a classification for it.
Those of you who know DDC (Dewey, all US will know it) know
how this works. DDC is pretty difficult as there is only one
single class assigned. But there are other schemes that e.g.
allow for more than one class to be assigned. Those are
simpler to build. One could try to set up such thing while
building the db.
(For a "classification": you just assign a number or some
characters and numbers that describe a feature in an
abstract form.)
>> We should not rely on manual classication, but something
>> like pattern recognition. Manual classification is
>> expensive and error-prone : just look at the mess with
>> bibliographic keywords. ? Tags are practical, but
>> unreliable. They should stay at the personal level.
>> Nothing very original here : I am only hinting as to why
>> expert systems did not fulfill the hopes classical AI
>> entertained about them.
> IMHO only manual classification makes sense for most
> databases.
Agree. Not only for professional reasons ;)
> Anyway I will leave classification to database creator. If
> it is done by custom PGN tags, it can easily be added
> automatically by external tool if classification for given
> database makes sense.
PGN tags have the disadvantage that they are not indexed in
scid and searching is _VERY_ slow. A classification could be
mapped on a flag like system which can be indexed and is
faster searchable.
>> Anyway, the biggest problem, IMHO, will be with the
>> headers. Chess database are organized around real games.
>> Exercices based on real game can provide information. We
>> just have to decide how to tell the user that it's just a
>> game fragment in the game list. (Suppose we have 10
>> exercises out of a single game.)
> Why not give original game headers?
I think Benoit refers to those games where you don't know
them. See my other mail how this could probably be handled
using UIDs.
>> But for endgame, that is already more difficult. How are
>> we to indicate that it's the Vancura position we are
>> practicing ? A line with question marks is very
>> uninformative. Maybe we should think about this, while
>> thinking about the normalization of header information.
> Custom tag 'Vancura position' is best for me. It allows
> both easy studying and training.
This involves building up a thesaurus, ie. (simplified) a
sorted list of keywords. You'd best generate something like
Endgame
Rook endgame
Vancura Position
Syn: RP vs. R
Syn: RP:R
Syn: Rook + Pawn vs. Rook
Point is that you may have rook endgames without individual
names and you need a class for them. Building something like
that might look like using a cannon to shoot a sparrow but
it is really worthwile.
Building up something like that can also be done while
creating the DB and adopting on the fly. Both,
classification building and thesaurus setup are not entirely
easy, but one can surely start it on a very practical level.
Note: If you build a thesaurus it makes sense again to
assigne UIDs to the terms as then you could translate it
easily to another language.
--
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
