Pascal Georges wrote: Hi!
> I just committed a first version for Metadata support > for Scid databases. I used a set based on Dublin Core. > (http://dublincore.org). > > In general we could consider to use the metadata files > (currently called sme) also as a tool to provide > specific settings for a database. But that is > currently just an idea. > > > I don't understand the benefits of it, from a practical > point of view. Bases have a description field and > attributes that should be sufficient. Well, this is a first edition of metadata and Dublin Core is what it says: a CORE set. In some areas it is that much a core that it's hardly usable (e.g. to cite an article from a journal is not possible with this set). Anyway, it already contains some legal aspects like license, rights holder, author e.g., and some rudiementary data needed for long term preservation plus also some extended fields beyond description. This is available in a structured form for easy extraction (author e.g. is not in description but in an author field). Dublin Core is really one of the very wide spread metadata schemes used today. The XML created should allow other applications to access the description of the database easily. Think of a web application that serves a bunch of trainings bases and that could then extract e.g. all such bases which are freely available due to Creative Commons or GPL. "Instructional Method" e.g. could get keywords like "Mate in 1", "Pawn Endgames", "Kingside Attack", "Tactics"... whatever. But also in packaging up the contents of Scids website for some distribution. You may remember Akhers queries about "what license is this DB"? Provided each DB on our site has proper metadata this question is answered. Anohter idea here could also be that we move from the "sort bases into directories" philosophy to a "store bases somewhere", because by extracting the tags one would have the means of the DB already. Imagine a set of bases on a CDROM or a set of bases downloaded from the web. How should a newbe know how to sort them in? Another idea would also be to publish updates. Say your current DB says dc:coverage 2006 and dc:source http://scid.sf.net/bases/YearInChess.sg3 you could call a web service, discover that the same DB is available with "dc:coverage 2008" and you could fetch the new one to replace the old one. However, if you think in the direction of web services and so on I'm pretty sure that an XML set has some definite advantages to parsing "some strange string with a lot of {} that seems to come from some funny language nobody speaks these days". That is, it is also meant to be an interface for other services. And as I said, the set could easily be extended if there is some need. I could e.g. imagine that some variables within Scid are set by the metadata. E.g. for a trainings DB it might not make sense to have the PGN window open, or opening the DB should actually fire up an internal training function of Scid. -- Kind regards, / War is Peace. | Freedom is Slavery. Alexander Wagner | Ignorance is Strength. | | Theory : G. Orwell, "1984" / In practice: USA, since 2001 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
