Provide lookups for ISO 639-3 and ISO 15924 (both non-RDF controlled vocabs)

[sfolsom]

This request breaks our normal process for requesting a lookup because it's not for RDF data.

ISO 639-3 (language codes) can be downloaded as tab-delimited text (https://iso639-3.sil.org/code_tables/download_tables). For these we would want the language name and code to be searchable, both to be displayed in the context, and the code be the primary value similar to how the URI is treated in normal linked data lookups.

ISO 15924 is just an html table on a webpage on the official site (https://www.unicode.org/iso15924/codelists.html), so we would need to copy and paste this into table. The code, English Name, Nom français, and Alias would need to be searchable and display, and the code be the primary value similar to how the URI is treated in normal linked data lookups.

seeAlso: https://github.com/LD4P/sinopia_editor/issues/2804

[sfolsom]

LC uses a json representation: https://github.com/lcnetdev/verso/blob/master/data/vocabularies/ISO-15924-script.json to pull off the ISO 15924.

[elrayle]

Fields in the data for ISO639-3:

field name	ex value	description	potential use in QA
ID	eng	3 letter code	id
Ref_Name	English	Reference language name	label
Type	L	A(ncient), E(xtinct), H(istorical), L(iving), etc.	subauthority

other fields could be extended context, but QA does not support extended context for non-RDF at this time.

There are enough entries in this vocab that we would probably want to put it in a database.

It appears that the database approach doesn't allow for a subauthority. It would require a custom module to support subauthorities.

[elrayle]

Fields in the data for ISO15924:

field name	ex value	description	potential use in QA
Code	Arab	4 letter code	id
English Name	Arabic	Full name in English	label

This is a fairly small set, so we may want to put these in YML instead of a database table. May want to put it in a database just to make the API consistent.

[elrayle]

Are there ontologies that support a basic code:value specification? We could explore converting the data to RDF in order to support an RDF search through QA.

The problem with converting to RDF is the need to assign a URI and the responsibility to maintain that URI over time. Also, there can be a conflict if the authoritative data provider begins supporting RDF data. There may be a conflict with the way we supported the data as RDF.