Components Building Integration OIDs Editing
The new OGSL and signlist tool are not yet fully integrated into Oracc: this page explains what can be expected to work and what the plans are for further integration.
There are several components to OGSL and the signlist tools; some understanding of what they are is helpful for the following sections.
The signlist itself, 00lib/ogsl.asl in the ogsl project
The main processor for Oracc ASL (signlist) files
The Sign List Library--a library used by SX and other programs to load OGSL
The Grapheme Validation Library--a library used by the ATF processor and other programs to check transliteration; also uses SLL to check the validity of graphemes in transliteration.
The normal Oracc build is not fully functional in the ogsl project; for now two elements of the build are supported:
oracc update
oracc build
This runs sx on ogsl.asl and rebuilds the data file which is used by SLL: this means that changes such as added values will be recognized on build-oracc after an oracc update. It also rebuilds the auto-generated pages on missing lists and Unicode data.
This only rebuilds the portal pages, which means that if edits to ogsl.asl have changed the missing lists or Unicode data, those changes will be visible on the new portal pages on build-oracc.
At present oracc serve is not
supported; this will change as soon as the OGSL/SSL/GVL
integration is complete. For now this means that changes made to
OGSL will be effective on build-oracc, but will not propagated to
the Munich build server or to the public servers.
One of the reasons for rewriting the signlist tools was that there were four different ways of accessing signlist data in Oracc subsystems. Integration with the ATF processor (in Oracc 1 this is 'ox'; in Oracc 2 it will be 'ax') is complete and under testing.
Integration with the online signlist that is part of OGSL and ePSD is functional but needs some revision.
Integration with glossary building is untested.
OGSL is partly integrated into the Oracc persistent IDs (OIDs) subsystem: sx looks up OIDs in the central OID table and reports any signs that do not have OIDs. For the moment these need to be added manually, but this will be rectified very soon.
The plan is to integrate OGSL more closely with the OIDs in the near future. It is likely that all the existing OIDs for signs will then be revoked and reissued to provide a clean start, after which changes in sign-names, removal of signs, and the physical merging of signs (not the simple tagging of mergers) will need to be curated with editing protocals as used in curating ePSD OIDs. It's not entirely clear how @forms will be handled with OIDs yet.
OGSL editing is open for business: values can be added (they do not affect OIDs); @form entries which reference existing signs or forms can also be added or deleted (they do not affect OIDs). @list entries can be added or modified.
Changes to sign or form names will presently cause warnings that OIDs are needed; for now it would be better to notate them with:
@sign |A.DU&A.DU|
@inote >|(A.DU)&(A.DU)|
This will allow a script to edit the OID table so that the OID for the former name now has the new name as its key.
Until OID curation begins signs can be added as necessary and Steve will add the OIDs as required.