SQL databases are often used to store correspondence tables between applications' internal codes and end-user labels.
The ASKOSI jar is already able to:
- access any table in any SQL databases with parameterized queries for the mapping to SKOS;
- make those tables available through an SKOS API and therefore as SKOS files;
- search and browse the tables
- validate the tables (duplicate terms, missing translations, loops in hierarchy, etc.)
Within a Tomcat container, this application can also be used to make the SKOS sources available in memory for other applications (shared libraries, shared classes, shared data).
Any SQL database (for instance, in http://www.windmusic.org, keywords of the Index are coming from one of the DSpace collections; authors are another one; publishers idem)
- Statically (Concept Scheme loaded at start up time)
- or dynamically (entries are retrieved and cached as needed: the Concept Scheme may be enormous)
It is dynamic: the SQL database can be updated and the SKOS source is updated too, making the updated version immediately available to all applications in the same Tomcat container. Static accesses (manually triggered reloads) can also be chosen.
The ASKOSI software presentation http://www.askosi.org/askosi_presentation.pdf gives this configuration example:
loaded at startup#
(or when the "Reload" button is pressed in ASKOSI)
ConceptScheme with the subjects in a DSpace collection:#
ConceptScheme with all users registered in a DSpace application:#
type=SQL pool=dspace title-en=Users title-fr=Utilisateurs title-nl=Bezoekers labels=SELECT distinct replace(replace(split_part(email,'@',1),'.','_'),'-','_') AS about, '' AS language, case when lastname ISNULL then replace(split_part(email,'@',1),'.',' ') else firstname||' '||lastname end AS label from eperson alternates=SELECT distinct replace(replace(split_part(email,'@',1),'.','_'),'-','_') AS about, '' AS language, email AS alternate from eperson