Migdal: 佐藤陽花

CLAコードの改めての紹介と、現況＆今後の展望

佐藤陽花 — Tue, 09 Dec 2025 03:05:32 +0000

らんらんアドカレ 9日目、待降節第二火曜日の記事です。前回の記事(一昨年)では中国語で書いたものの、結局誰も読めなそうな感じだったので日本語に戻します。

本当は今年こそは(語³アドカレに)記事を書こうと思っていたものの、人工言語アドカレ記事の存在をアドベント始まって暫くするまですっかり忘れていた大間抜けです(昨年は人工言語アドカレ記事の存在自体は覚えていて苔塔アドカレに名乗りを上げていたものの記事を落とした間抜けをやらかしたので、今年こそは...と思っていたんだけども....orz)

皆様お久しぶりです、佐藤陽花です。(往々にして方々で名前が出てきがちなうちの一人だし、多くの界隈人は私のことはご存知だと思うので、改めての自己紹介は省略します)

はじめに

さて相変わらずして人工言語多産の佐藤陽花であり、以前から継続して制作しているオェｼﾞｭルニョェーッ語 (オエル語)やオイナルシャルム語のほか、最近も制作しだしている共作言語や個人言語などの諸言語がありますが、数週間前に某所でCLAコードに関するお問い合わせと新規申請をいただいたこともあり、今回は個別人工言語の話題ではなく、CLAコードの現況と今後の展望について書いていこうとおもいます。

CLAコードといえばこのサイト、Migdal (SNS)にも重要な(記事(やその一部)の言語指定において人工言語を指定出来るように成り立たせている一つがCLAコードです (もう一つが同じくCL-KIITAの策定しているLIISコード及びその補助仕様))。

CLAコード - Conlang Layered Assignment

以下、人工言語Wiki記事や、個別申請における説明内容、CLAチーム内部の運用規範などを掻い摘んで、また整理して説明していきます。

CLAコードの概説

CLAコード(Conlang Layered Assignment コード)とは、ISO 639 に倣い、各人工言語のコードを規定するものです。このコードを用いることで、辞典データなどのデータベース上や、各種アプリケーション上・システム上で人工言語を取り扱いやすくなります。

2015年7月21日におかゆ氏により初版(CLA v1)が提案され、運用されていました。2021年8月5日に提案された試案(CLA v2)を経て、これをもとにCL-KIITA (人工言語知識情報・情報技術事業体)において現行版(CLA v3)の仕様策定が進められ、同8月17日に仕様の策定、9月2日に標準規格が発行され、以降これが運用されています。

CL-KIITA: 人工言語知識情報・情報技術事業体フォロー

人工言語知識情報・情報技術事業体(CL-KIITA, Conlang Knowledge Informatics and Information Technology Association)は、人工言語界隈の情報関連事業のための共同団体です(特定コミュニティ専属ではありません)。

CL-KIITA: 人工言語知識情報・情報技術事業体 · GitHub

人工言語界隈の情報関連事業のための共同団体です(特定コミュニティ専属ではありません)。辞書システム「ILDics」などの開発、及び人工言語コードなどの標準策定を行っています。 - CL-KIITA: 人工言語知識情報・情報技術事業体

github.com

コード仕様概略

CLAコード(CLA v3)こと人工言語層状割当コード(Conlang Layered Assignment Code)は、広い方から制作者(個人、共同、又は集団)、語族(語族・語派など言語グループ)、言語、方言の4階層から構成されていて(大雑把に分けられているだけなので層の名前にそこまで縛られる必要はなくある程度柔軟にできます)、それぞれ英小文字3字、3字、2字、2字のコードを割当られます。語族及び方言はないことも可能で、その場合は「未定義」と記録されます(「未定義」というネーミングはプログラミング界隈の用語なので余り気にしないでください)。

また制作者及び語族、言語及び方言はそれぞれ一つの名前空間を構成しており、制作者及び語族はグローバルに、言語及び方言は語族ないし制作者ごとにユニークなコードを持たなければなりません。

申請の方法と手続

CLAコードの申請には、まずそのコードの指し示す対象となる人工言語(やその方言等)の制作者(或いは代理者)たる申請者が、どのコードが良いか決めるところから始まります。

コードの決め方については(CLAコード仕様に基づかなければならないこと以外は)決まりはなく、申請者の自由となっています。なお、概ね次のような手法が慣例になっています。

原語名称のASCII英字への翻字をベースとする。
数字はa, b, c, ...或いはi, ii, iii, ...などに置き換えるか、又はその言語/方言による読み方を用いる。

また、申請において希望するコードの各々(各層)につき、何の何処の部分からどのように採ったのかの釈明を添付する必要があります(これをもとに申請されたコードが妥当かどうか判断します)。その他、その人工言語(或いは方言)が実際に存在することを明らかにするもの(資料サイトや紹介記事・辞書など)の提示をお願いしています(なお、制作者が審査担当者と知己深く、存在が既知である場合は提示の省略を許すことがあります)。

コードの申請は、制作者/語族/言語/方言の各層に区分して行い、その各々について個別に申請・審査されます。既に発行された制作者コードに属する言語コードの場合、言語コードのみの申請者で十分であり、他のケースも同様です。

各々の層について、申請において必要な項目は、上記に示したものを含め次の通りです。

層の区分
コード要素
コードの選定の釈明
対象の存在証明
原語名: その言語の自称(内名)をUnicode記録可能なよう適宜転写等を施したもの
日本語名: 主に日本語やアジア諸言語中で言及される場合のための名称で、漢字(変種(地域字形)を含む)及び仮名(変体を含まない)を用いることが出来る
英語名: 主に欧文中で言及される場合のための名称で、ダイアクリティカルマークや合字を含むラテン文字を利用することが出来る。
- 目安として、Latin-1、Latin-2、Latin-9及びLatin-10、並びにこれらに(単体又は合成済み形で)出現するダイアクリティカルマークや合字が利用可能
読み仮名: 主に口頭で読み上げたり記述上においてソートする場合のための表記
ASCII翻字: 主にシステムの内部で取り扱う場合のための表記で、原語名を標準ASCII英字に縮退転写させたもの

この他、規則及び慣習に従って審査チームが独自に採録し記録する項目があります。

コードの申請が提出されたときは、申請チームは速やかに審査に着手します。申請者と対話したり調査したりしつつ、審査事項・留意事項について点検し(不備があれば適宜修正や追加説明を求め)、問題ないことが確認できたら承認して付与・発行します。

なお、申請の結果、申請チームの一員たる審査者による最終判断は次の3種類あります。

承認: 審査の結果申請内容に問題が見られず、かつ申請を受け入れることができない事由が存在しない場合
棄却: 申請内容に不備が存在し、かつそれが修正されない場合
留保: 本人申請原則への抵触など、申請自体には問題ないが、申請を受け入れることができない事由が存在する場合 (その事由及び解除条件を明示の上で行われます)

審査チームについて

CL-KIITAの中でも特に、コード割当総部 (Code Assignment Authority; CAA)という部署がコード類の策定＆運用・発行を担っています。コード割当総部はコード類やシステムの規格策定・仕様策定を担う「策定チーム」と、コード類の運用・発行を担う「審査チーム」に分かれています(往々にして共通メンバーがいますが)。

審査チームのメンバーは、全体の運営管理と審査・発行を担う審査権者、雑多な事務処理や記録管理を担う総務書記、そして外国語による申請や問い合わせに対する窓口通訳とに役割分担しています。なお、審査チームの現行のメンバーは次の通りになりますので、お見知りおき下さい。

審査権者 (= 審査担当者)
- 佐藤陽花 (@halka_ffez)
- Ziphil (@ziphil)
- Xirdim (@xirdim)
- かえる (@kaeru2193)
総務書記
- Atridott (@atridott)

手動発行体制の報告と経緯

CLAコードv3の仕様策定・運用開始以来、(同じくCL−KIITAメンバーの)Ziphilさんの開発によるCLAコードPortal(Webアプリ)で申請及び審査・発行を行なっていました。しかし、当時用いていたホスティングサービスに関連する事情で、2022年11月28日付けにて当該Portalの運用を終了し、(次世代Portalの開発を続行しつつ)手動体制にて発行してきました(2023年4月16日付けで「後ほど正式な発表をする予定」と言及していましたが、まさかの2年半越しとなってしまいました)。

ここMigdal(SNS)を管理しているA.I.御大による機能紹介記事には未だポータルへの言及とリンクがありますが、現在使用出来ないのでご留意ください。

(後ほど正式発表すると言及していた)非正式発表曰く、

半年〜一年以内には後継システムを開発・稼働させる予定ですが、現在は暫定措置として人力による手動登録・管理を行っています。

このような事情のため、コード付与をご希望の方やコード照会、お問い合わせなどは当分の間、本拠CL-KIITA鯖やその他DLL鯖等、KIITA言語コード担当者(総代表の私佐藤陽花、主任のじふぃるさん、又は事務役のXirdim)のいる汎人工言語鯖や、KIITA言語コード担当者本人のDM等で、当該担当者までお申し付けください。

(但し多忙等の理由で対応にお時間を頂くことがありますので、ご理解ご了承の程宜しくお願い致します)

という内容となります。

(ここでも「半年〜一年以内には後続システムを」と言及していますが、相変わらずして何年も時が経っているものの、余り進捗が出せず、後続システム始動の目処が全く見えない状況です)

CLAコードはかねてより手動発行体制となっているわけですが、まずは簡易API＆簡易ツールによる半自動の手動体制にしようというのが私達CLAコード審査チームの当面の思惑です。

実際、数日前から私が簡易API＆簡易ツールの仕様作成＆開発に取り掛かかっているところです。

CL-KIITA / Temp_CLIR

Temporary System of Conlang Assignment Management Table

Temp CLIR

Temporary System of Conlang Assignment Management Table

Included Packages

concode_lib pkg: Temporary common library of CLA and other codes
clir_kit pkg: Conlang assignment management tooklit as CLI application
clir_serve pkg: Conlang assignment management service as Web API server
clir_web pkg: Temporary conlang assignment portal as simple dynamic Website

GitHub で見る

手動発行体制の手続

手動発行体制では、本拠CL-KIITA鯖やその他DLL鯖等や、あるいはDM等でのメッセージにおいて、はたまた対面やVCでの会話によって随時受付ております。申請者本人が所定の申請様式を備えたメッセージないし電子ファイルを審査チーム成員に送付するか、あるいは審査チーム成員が申請意思及び申請内容を聴取してこれら所定様式に起こします。このあと、通常の手続と同様に審査・発行がされます。

手動発行体制においては、発行したコードはDiscordのアナウンス機能による告示をもって有効としてきました(なお、それ自体によって有効となる訳ではありませんでしたが、Discordのアナウンス機能による告示自体は以前のポータル発行体制においても用いていましたし、次世代ポータルでも同様とする予定です)。なお、このアナウンス機能のみだと到達範囲が思いの外狭く、有用には周知出来ていないきらいがあったので、有難いことにみかぶるさんが纏めリストを作ってくださいました。

CLAコード一覧(2023-12-25)

みかぶる・ ’23年12月24日

#人工言語

CLIR Assignment Management Table

ここ最近はCLIRという(CLIRのCとRはそれぞれConlangとRegistryですが、間のLとIが自分でも謎)という基本台帳(現時点ではGoogleスプレッドシート)及び周辺プログラムを使って管理しています。

(’25年12月9日午後追記 ― CLIRのIはIdentifiersでした)

さいごに

末筆になりますが、皆様におかれましては今後ともCL−KIITAとCLAコードへのご理解のほどよろしくお願いします。また、CLAコード及びシステムの策定や運用、発行に協力したいひと、興味関心があるひとは非常に大歓迎ですので、どしどしお声がけ下さい。

アドカレ枠の余剰が残っていて、CLIRの実装がある程度終わって、かつ記事執筆の時間的余裕と体力的余力が残っていたら、CLIRの基本仕様と使い方を紹介する続編アドカレ記事を書きたいと思います(期待しないでください)。

ようやく此処でLIISコード対応が実装されたので、事(LIISコード提案)の発端の記事の設定(言語名)をLIISコードにて設定さるよう修正してみた

佐藤陽花 — Wed, 22 May 2024 05:00:23 +0000

ここ使ってくれる人が増えて色々な言語の紹介記事が流れて来て良いなあ。皆の言語で書かれた記事も見てみたい

佐藤陽花 — Wed, 22 May 2024 04:37:05 +0000

LIISコードのIETFシステム対応化についてとイスクイルのLIISコード発給の告示

佐藤陽花 — Mon, 22 Apr 2024 12:44:44 +0000

はじめに

みなさんお久しぶりです。ちょいちょいお目にかかりますCL-KIITA代表の佐藤陽花です。

私たちCL-KIITAは、汎用の人工言語コードであるCLAコードと並行して、LIISコード(Language Information Interchange Supplementary Code)を(一応)策定・運用・管理しています。
これは、コンピュータ上での利用欲求の高いものの既存のISOコード、CLAコード、或いはIETFタグなどの言語コードに採録されていない、或いは不十分であるものについて、適切な状態になるまでの間補助することを目的としています。
なお、詳しくは次の記事をご覧ください。

LIISコード：言語情報交換補充コードの提案

佐藤陽花が CL-KIITA: 人工言語知識情報・情報技術事業体へ執筆・ ’22年2月23日

#cl_kiita #人工言語 #自然言語 #言語コード

規格仕様の補遺

原提案に規定漏れを見つけたので、この場を借りて補遺させていただきます。

LIISコードに使用可能な文字種はCLAコードと同様にASCII英小文字のみとします。また、原語名称のASCII転写によって個々のコードを定めることを原則とします。

LIISコードのIETFシステム対応化について

現行の情報システムにおいては残念ながらIETF形式しか扱えず人工言語の指定に難があるものが多くあるので、CLAコードにおいてやむなくIETF対応形式への変換措置を設定しているところでありますが、それと同等の措置をLIISコードにも同様に適用する手法を規定します。

すなわち、次の通りとします。なお、k, l, aの部分に対応するものは原提案と同じです。

x-liis<kk>-<llll>(<aaa>)

記事投稿サイトや辞書など、CLAコードでの識別を実装しているソフトウェアやサービスの管理者に置かれましては、同様にLIISコードも対応していただくよう宜しくお願いします(特にここMigdal(SNS)の管理者であるAIさん ( @a_i ))。

※とはいえ、正規化の処理は(コード管理システム以外では)プログラム上では必須ではなさそうです。

イスクイルのLIISコード発給の告示

イスクイルを用いて記述された文章を識別子を与えてたいという欲求が存在し、人工言語コードの規定の求めがあったので、これに対処することにしました。
調査したところイスクイル全般を指示するen:ithkが指定発給してありましたが、請求人の陳述によればイスクイルの各版は互いに違いが大きいとの指摘があったので、別言語として扱うことが妥当であると思料するところであります。
したがって、イスクイル制作者のCLAコード申請のあるまでの間の補助として、次の通りイスクイル3及びイスクイル4のLIISコードを指定し発給します。
なお、en:ithkについては従前指定のものについて指示対象の変更を行うものとなります。

en:ithk：イスクイル全般、特にv1(とv2)
en:elrt：イスクイル v3　　(v3非正式一般自称/ɛ'laɾ.tkʰa/より)
en:matr：イスクイル v4　　(v4非正式一般自称/mal'ɤʊ̯θʁaɪ̯t/より)

※CLAコードは原則として制作者本人の申請を要するため、LIISコードでの対応を行います(制作者本人と連絡がつく場合、(並行して)本人に申請を訴求してください。(その方が望ましいあり方ではあります))。

Cotec: Conlang Table Expression powered by CSV 【CLaKIS RFC】

佐藤陽花 — Tue, 19 Dec 2023 14:13:13 +0000

皆さんおはこんばんにちは。この界隈ではもはや知らない人はいないであろう佐藤陽花です。実はアドカレ記事の次は‘人工言語創作における構造主義の理論と実践’をテーマとして記事を書こうと思っておりましたが、みかぶるさんの働きを目にし、その人工言語の古今東西調査記録に貢献しようとこの記事の筆を取った次第です。

さて、非常にありがたいことに数日前からみかぶるさんが、現在存在する人工言語を悉皆に調査し、人工言語一覧表(令和最新版)を作成・随時アップデートしてくださっています。本規格は、その働きを助けるために、一覧表の元データテーブルの記録・メンテナンスの簡易化を目的として、この用途のために安定的に利用できるデータフォーマットを提案するものです。規格仕様はRFC(Request of Comments)の状態に置かれており、パブリックコメントとして関係者を始め皆様のご意見を募集しております。

諸元

名称: Cotec
名称(長形): Conlang Table Expression powered by CSV
拡張子: .ctc
規格番号(暫定): CLaKIS/RFC DX2024-1
規格バージョン: v0.18

仕様 (RFC)

Cotecは、CSV仕様上に構築されるテキストデータとする。Cotecに合致するデータは、CSVとしても合致する。
列区切りのカンマの左右の空白は無視される。後述の通り、処理系では両側の値に回収された後両端トリムされる。

型付の値をカンマ区切りで並べた行の並びを一つのデータテーブルとする。第0行にメタ行を、第1行にラベル行を、第2行に型宣言行を配し、その後第3行以降任意行数分のデータ行が続く。

メタ行は第1列にデータ行の行数列数、第2列にテーブルタイトル、第3列に作者名、第4列に原始作成日時、第5列に最終更新日時、第6列にライセンス名、第7列にライセンス表示、第8列に拡張仕様コードが記載される。
行数列数は{行数}x{列数}の形式で、メタ行の日時はISO形式に準拠して記載される。
拡張仕様コードはUnsigned Intで、ビットフラグ管理される。
ラベル行、型宣言行、及び全てのデータ行の列数は必ず等しい。
ラベルは[A-Z][A-Za-z0-9]*)((-|_|\.|:)[A-Z][A-Za-z0-9]*)*の正規表現に従う。拡張仕様に基づきラベルのレンダリング文字列を規定することができる。

メタ行、ラベル行、型宣言行、及び全てのデータ行の規定セルを除く全ての任意セルはコメント乃至メモのためのセルとして利用することができる。

値には空白を含んでも良いが、値の前後にある空白はトリムされる。
値にはエスケープされないカンマ、改行、空白、アンダースコアは出現しない。
また、Array型リテラル以外の型の値ではエスケープされないセミコロン、Pair型以外の型の値ではエスケープされないコロンは出現しない。SString型においてはリテラル以外ではエスケープされないイコール及び丸括弧は出現しない。
エスケープはいずれもバックスラッシュを前置することによって行う。

Cotecの型は次の通りである。なお、任意の英字T及びUについて、型名の箇所で[T]とあるのは総称型を、T: Uとあるのは型ヒエラルキー上U型の子としてT型が存在することを表し、正規表現の箇所で{T}とあるのはT型のリテラルが埋め込まれることを表す。Any型以外で親となる型が示されていない型は全てObject型を親の型とする。

Any
- desc: any no-typed values acceptable, very very danger, be careful to use
Object: Any
- desc: same as Any excepts Null
Null: Any
- desc: null
- regex: null|nil|~
T? on T
- equals: Union[T,Null]
Type
- desc: 型を表す型
- regex: {TypeKernel}(\[{Type}(,{Type})*\])?\??|({Hom}|\({Hom}\)\?)
TypeKernel
- desc: 型名のうち固有リテラルでない部分
- regex: ([A-Z][A-Za-z0-9]*)(_[A-Z][A-Za-z0-9]*)*
Label
- desc: ラベルの型
- regex: ([A-Z][A-Za-z0-9]*)((-|_|\.|:)[A-Z][A-Za-z0-9]*)*
BinArray[B] on B where B: Binary
- desc: binary array with unit
NString
- desc: Natural string
- regex:
SString
- desc: エスケープされないイコール及び丸括弧が出現しないことを除きNStringと同様
Bool
- desc: 2-value boolean
- fmt: true, on, yes (as true) / false, off, no (as false)
- regex: (true|on|yes)|(false|off|no)
ANumber
- desc: Auto (unique) number (integer) within identity mainly-for primary key
FNumber
- desc: Fixed digit-count (unsigned) number (integer)
SNumber
- desc: Signed number, with infinity and NaN
UNumber
- desc: Unsigned number, with infinity and NaN
Binary
- desc: sized bit array
Byte: Binary
- desc: byte size(8 bits) value
Half: Binary
- desc: half size(16 bits) value
Word: Binary
- desc: word size(32 bits) value
Url
- desc: URL
Date
- format: (yy|')yy(.m(.d(.h(.M)?)?)?)?
- regex: (([1-9][0-9]?)|')[0-9]{2}(\.(([0-9])|(1[0-2]))(\.(([1-2]?[0-9])|(3[0-1]))(\.((1?[0-9])|(2[0-4]))(\.([1-5]?[0-9]))?)?)?)?
DateRange
- regex: ({Date}-{Date}?)|(-{Date})
LangCode
- desc: 言語コード識別コード付きの言語コード
- regex: \{[a-z]{3}[a-z0-9]\}[a-zA-Z0-9_~\-]+
LangClass
- equals: Union[ClassicClass, Array[MoyuneClass]]
ClassicClass
- desc: 俗にSe分類とも呼ばれる伝統的な分類
MoyuneClass
- desc: モユネ分類の各々の値。ASCII英大文字三字(のenum)
Ariority
- desc: アリオリ性
- fmt:
  - Unknown: 不明
  - Mixed: アプリオリとアポステリオリの混合
  - Pri: アプリオリ(詳細不明)
  - Pri.Strict: 厳格にアプリオリ
  - Pri.PartPost: 原則アプリオリだが部分的にアポステリオリ
  - Pri.AcceptPost: 原則アプリオリだがアポステリオリも許容
  - Post: アポステリオリ
  - Post.Strict: 厳格にアポステリオリ
  - Post.PartPri: 原則アポステリオリだが部分的にアプリオリ
  - Post.AcceptPri: 原則アポステリオリだがアプリオリも許容
- regex: Unknown|Mixed|Pri(.(Strict|PartPost|AcceptPost))?|Post(.(Strict|PartPri|AcceptPri))?
Array[T] on T
- regex: {T}(;{T})*;?
Pair[K,V] on K, V
- desc: K型の値とV型の値の組
- regex: {K}: {V}
- prop: 型パラメタについて結合則及び反交換則を満たす。
Hom[K,V] on K, V
- desc: ホム類。K型の値を始域、V型の値を終域とする射の族
- prop: 型パラメタについて結合則及び反交換則を満たす。
- regex: {Type}->{Type}
Union[T,U] on T, U
- desc: T型もしくはU型
Nominal[A] on A
- desc: 別名義と注釈も記載可能な名義
- prop: 型パラメタについて結合則及び交換則を満たし、またPair型及びHom型に対する分配則を満たす。
- regex {SString}(={SString})*( \({A}\))?
ArrayOr[T]
- state: deprecated from v0.8, for removing
- desc: same as Union[T,Array[T]]
MapFor[T,label] on T (experimental)
- state: pre experimental
- desc: 指定のlabelと写像関係にあるT型の値。Array型の場合長さは等しい必要がある。

拡張仕様コードは次の通り。使用する拡張仕様の拡張仕様コードの和を用いる。拡張仕様を用いない場合のデフォルト値は0で、記載必須値とする。

拡張仕様1及び2では、メタ行とラベル行との間に追加メタ行が2行追加される。追加メタ行第1行は設定的用途のため、同第2行はメタ情報的用途のために用いられる。

1: 概要、経緯及び更新情報の記載のための追加メタセル
2: 言語別ラベルレンダリングのための補助テーブル
4:
8:
16:

拡張仕様: 概要、経緯及び更新情報の記載のための追加メタセル　(コード1)

追加メタ行第2行第1列から第3列までにそれぞれ概要、経緯及び更新情報がNString型に準拠して記載される。

追加メタ行第1行第2列にその他の追加メタ情報の項目数を記載する。概要、経緯及び更新情報のみの場合は0と記載される。

その他の追加メタ情報は追加メタ行第2行第4列以降にラベルと値の組みで記載される。ラベルはラベル行のラベルと同様の形式に準拠して、値はNString型に準拠して記載される。

拡張仕様: 言語別ラベルレンダリングのための補助テーブル (コード2)

追加メタ行第1行第2列に補助テーブルの(ラベル行を基準とした)オフセット行数と長さ行数が{オフセット}-{長さ}の形式で記載される。

補助テーブルの列数は、データ行の列数とその他の追加メタ情報の項目数の和に4列加えたものとする。
補助テーブルにおいて、各行第1列はレンダリング言語をLangCode型に準拠して記載され、同第2列に対応するレンダリング文字列をNString型に準拠して記載される。レンダリング文字列は、ラベル行、概要、経緯、更新情報、及びその他の追加メタ情報の順序で記載される。

懸案事項

総称型のネストのリテラルはどうしようか
列の間でのセル値の紐付け制約の記述の方法はどうしようか

上載仕様: 日本語圏人工言語リストにおけるCotecのラベル及び型に関する定義

messier,name,kanji,desc,creator,period,site,twitter,dict,grammar,world,category,moyune,cla,part,example,script 
Any,Array[NString],Array[NString],Array[NString],Array[NString],DateRange,Array[Url],Array[Url],Array[NString],Array[NString],Array[NString],Array[NString],Array[MoyuneClass],Array[LangCode],Any,Array[NString],Array[NString]

我正在做的多少人工語言簡介(和CLA碼近況)

佐藤陽花 — Wed, 13 Dec 2023 23:34:34 +0000

大家好歡迎回到我的文章!這是降臨節日曆關於人工語言第十四天的文章。

昨天的由yuzuru_sofia影片關於yuki-mima看起來讓做向知道得人工語言不詳的人、還這個語言yuki-mima的構詞形態看起來跟Lineparine語的那個很像、就使用後綴助綴而言。
我想說關於我正在做的多少人工語言、還告訴您們CLA號碼的近況。
請您們真快樂的閱讀這文章、和使用這個我的語言!

外語(Oinarшalm語)

那麼、我來談談我的語言。雖然我覺得很多人都知道、我有做過好多語言、我將提出與講我最近開始做的一些語言。

先、我的語言節目有在Xaléh語触動下我開始做的個人語言。這叫"Oinarшalm語"還稱"外語"。
這語言是為了我內省和分析我自己如感知這世界的我正在做的東西。這沒有虛構世界、一切依靠這實際世界。

那麼、我們看看這語言的詳細一下。

基於語言本質上是表達,傳遞和記錄資訊的方法的基本認識、我做使其具有系統化與結構化的文法。例如、以話題優先、將詞組從已知到未知、從廣泛到詳細排列;與主詞沒有特權、動詞的論元被平等對待;還將動詞放在前面、並闡明動詞所用論元的數量和類型。
還、這語言有施通和主次配列、被設定為了讓施事論元和受事論元作用在單一核心變元。

然後、詞彙是按拓樸結構組織和創造的。例如:

愛情分為四類:真愛,親情,友情,性愛
碗按材料和用途分類

再、透過這種方式、他很據數學原理探究了資訊結構的深處、並建構了一個可以進行邏輯分析字詞系統。

為了未知語言破解小組的多少語言

然後、我來談談青蛙君我提案和使發展的語言遊戲。
這是三年前讓提案與本月重新啟動、叫"Langdon Squad"還是"未知言語解読班"、還稱"未知語言破解小組"於中文。這個遊戲是這樣的:每一種未知語言都有"本相之石"的實體;透過與這實體進行對話、我們可以提取知語言的片段;透過(模擬)實地考察、我們將破解未知語言並掲示這個語言的本相。

由於遊戲的性質、我無法告訴您們該語言的詳細資訊、但我提供我們從一開始就準備好的一種未知語言"Jejbiq"、並且一種強調文法的語言、就像我平常創造語言一樣。此外、我很快正在準備另一種未知語言。

CLA號碼的近況

是啊、雖然從外部看不出任何進展、但CLA碼在過去幾個月一直在穩步改進。我們目前正在開發和實作註冊表中的資料記錄結構以及主機(客戶端和伺服器)之間的資料交換方法。
最新的一項是為每種語言變體(語言、片他)的元資訊建立一種資料格式。

我謹通知您們、我們目前正在手動註冊CLA碼。如果您想要您自己語言的CLA碼、講告訴我們。
(如果您能多捐一點、我們不勝感激。這些都會更快完成。)

Migdalの正式始動に寄せて - 原典引照版

佐藤陽花 — Sat, 30 Sep 2023 14:33:47 +0000

ここMigdal SNSが(試行期間を終え)正式に始動した際に献呈した祝辞「Migdalの正式始動に寄せて」が、ここ最近(CL-KIITA宣言と同様に)人工言語による翻訳のお題と化しそうな機運があります。

しかし、この祝辞は新旧約聖書や映画「パプリカ」からの引用や翻案が多く、特に聖書から引用や翻案されている部分は聖書/キリスト教として特有の意味や事情を背景として持っており、人工言語やその他の言語に翻訳する際に注意する必要があります。なので、祝辞を翻訳する皆様の参考として役立たせるため、祝辞本文のそれぞれについて引照を附し注解を行うものして本記事を提供いたします。

なお聖書箇所を引照している部分において引用している章句は新共同訳に拠ります。また箇所記載の直後に角括弧で記されているのはページ数で、順に新共同訳、聖書協会共同訳のものとなります。聖書をお持ちでない方は㈶日本聖書協会の聖書検索にて(箇所記載の)書名・章・節を入力し検索することで章句を閲覧できます。

Migdalの正式始動に寄せて　(原典引照版本文)

東の方から誕生した人工言語の集いの場、Migdalの正式始動を祝して。

東の方(ひがしのほう): 東方(とうほう)ともいう。場所/位置ではなく方向であることに注意。半ば東方Projectとも言葉掛けされているが、この箇所に特に深い意味はない。

全地の人工言語よ、産声を上げよ、育てられよ、地に満ちよ。いちじくの青い実が、大風に揺さぶられて振り落とされるように、全地の人工言語は、我々愛好家の知性により生み出され、使われる。

全地(ぜんち): 全世界と同じ(諸共同訳聖書及び正教典礼における和訳を使用)。以下出現箇所において同様。産声を上げよ、育てられよ、地に満ちよ：「産めよ、増えよ、地に満ちて」(創世記1章28節第2文<旧2/2>)「産めよ、増えよ、地に満ちよ。」(前掲書9章1節第2文)<旧/10>)より。
いちじくの〜振り落とされるように: 「まるで、いちじくの青い実が、大風(おおかぜ)に揺さぶられて振り落とされるようだった。」(ヨハネの黙示録6章13節第2文<新459/447>))より。
いちじくの青い実: 果実であれば何でも良いわけではなく、知恵の実である「いちじく」だからこそ成り立つ表現である。また「青い」というのは物体の色自体を指しているのではなく、(少なくとも完全には)熟していないということを表す。非商業創作物である以上多かれ少なかれ未熟な点があるのが当然であり、したがって未熟なことを理由に躊躇ったり退けたりするものではなく、また完成度に関わらず受け入れられるという含意がある。

初めより神と共にあり、またこの世界の万物を成しているあらゆる輝ける言語、全地の言語のもとに生まれた新たな言語が、またそれら言語に関する記事が、積み重なり、塔となるように、その命にて世界を、暗闇を照らすように。

初めより神と共にあり: 「初めに言(ことば)があった。言は神と共にあった。」(ヨハネによる福音書1章1節第1文〜第2文<新163/160>))より。
世界の万物を成している: 「万物は言によって成った。」(前掲書1章3節第1文<新163/160>)より。語彙によって世界のあらゆる事物や実体が弁別され、個々のものとして認識されるようになるのです。
積み重なり、塔となるように: ここMigdal SNSの名前の由来でもある、かの有名なバベルの塔(創世記11章<旧13/13>)のこと。
命: 聖書において世界最初の女性の名前エバがヘブライ語で「命」を意味することから。
世界を、暗闇を照らすように: 「神は光と闇を分け」(前掲書1章4節第2文<旧1/1>))「光る物があって、地を照らせ」(前掲書1章14節第3文<旧1/1>))などより。

現実の自分、創作世界の自分。どちらが本当の現実かは関係ない、どちらの自分も真実であり、肯定されるべきものだ。

「夢」を「創作世界」と改めて用いている。映画パプリカのセリフ由来のはずだが出処不明。

祝福された現実を生きるために、全地の愛好家よ、人工言語に取り組め！

祝福された現実を生きる: 映画パプリカのセリフ由来のはずだが出処不明。

Migdal、人工言語の門から！今こそ、青空に向かって凱旋だ！

今こそ、青空に向かって凱旋だ！: 「今こそ青空に向かって凱旋だ！」(パプリカにおける島所長によるセリフ)より。

進め！集まれ！人工言語の愛好家たちよ！我々の「大きな夢」を成し遂げ「人類の巨大な歴史的宝庫」とするために！

進め！　集まれ！: 「進め！　集まれ！　私こそがお代官様！」(同島所長によるセリフ)より。
我々の「大きな夢」〜とするために！: 映画パプリカのセリフ由来のはずだが出処不明。

　　
(日時署名略)

コメントに応じて変化する世界

佐藤陽花 — Fri, 07 Jul 2023 17:28:07 +0000

Öphëtqa語のコメントから、？？？？世界が生まれました。

？？？？世界にはまだ名前すらありません。

みなさんのコメントに応じて、世界が変化していきます！

ルール

コメントはどんな内容でもＯＫ。
複数回コメントしてもＯＫ。
このページは毎日最低１回更新します。
採用済みのコメントには私がいいねを付けます。
この章より下の全ての項目は、コメントをすることで変更できます。
この企画は、記事「コメントに応じて変化する言語」と相互にリンクしています。
- それぞれにおいて、自己の企画だけでなく、リンクしている先の企画にも影響を与えます。
- 《コメントに応じて変化する言語》と《コメントに応じて変化する世界》は一心同体、三位一体！
- 言語のほうでは白紙のイチからのコメントであるが、こちらでは多少土台を作ってあります。

コメントに応じて変化する言語

ンソピハが Öphëtqa言語＆世界(仮称) へ執筆・ 7月5日・約 8400 字/語

#人工言語 #参加型企画

世界

Öphëtqa語が話される地域が存在する世界。

国家と地方区分

大部分を占める固有の地域のほか、一部には日本国のうち東京都、愛知県、福島県、またイギリスのうち西ヨークシャー、ウィンチェスター、タムワースがそっくりそのまま転移してきた地域もある(ソ・ラキメ共和国における奈良県のように)。

？？？？連合帝国

連合帝国と各構成国が主権を享有する国家連合たる国家で、帝位は選挙君主制度による。標語は「我ら諸国の結合たる連合帝国万歳」。

構成国として強い政治力を持つ数箇の王国や大公国があり、加えてその他の君主制国家がある。

連合帝国の最大の地方区分は構成国たる領邦国であり、また主要な地位を占める？？？？王国、？？？？？？？王国や？？？？？大公国では、領邦国に次ぐ地方区分は“道”である。

この“道”(地方区分)のひとつに、Ömpharrakka道(Ömpharrakha /ømpʰar-rakʰa/, 漢訳: 薔城道)がある。この地名は、“薔薇の城”を意味するÖmphar Rakha ‹属格›に由来する(語彙部分はそれぞれ城-薔薇。属格接語は地名となっているためか落ちているようだ)。

連合帝国の諸首都には多くの出稼ぎに来た人(出稼ぎ一世、出稼ぎ二世)がいる。

自然地理

プレート

気候

？？？？連合帝国の領土は広大で、その気候も地域によってさまざまだが、温暖湿潤気候に属している地域が多い。それらの地域では古くから水害に悩まされてきたが、近年は治水技術の発展に伴って改善している。

土壌

植生

社会地理

交通

社会

民族

言語

Öphëtqa語が、上記の？？？？連合帝国の第一公用語として用いられるほか、各地において国際共通語の1つとして通用する。

上掲の通り諸首都等へ出稼ぎに来た人などが多いためか、今目の前で話されているのが標準語なのか方言なのかが謎になり、言語調査の折標準語として報告された内容が実際方言のものだったり、報告される音韻・文法等が頻繁に変わったりするという事々案々がしょっちゅう発生する。

宗教

Tqöldöl教

この世界ではTqöldöl /t'øldøl/ という宗教の信仰が広く信仰されており、？？？？連合帝国の国教もtqöldöl である。

Tqöldöl はアニミズム、つまり万物に宿る精霊を信仰する宗教である。

Tqöldöl では、「万物に宿る精霊」をšykh /ɕykʰ/ と呼ぶ。

これは、動物 (いうまでもなく我々人間も含まれる)、植物、岩石、土だけでなく、視認できない (困難な) 大気や、物体として存在しない炎、生物間の愛などの象徴的な事柄にも宿るとされる。

Tqöldöl教では太陽が最高神とされている。しかしTqöldöl教の戒律では、太陽を拝んではいけない。あまりの恐れ多さゆえに、直視すると目を痛めてしまうのだ。代わって、雲が太陽の化身として扱われ、様々な形で崇拝されている。占い師は雲の動きからその日の運勢を占う。

他の宗教

Tqöldöl の他に、

qakqë /ʔak'ɜ/
khoo /kʰoo/
lepha /lepʰa/
sadvha /sadⱱa/
tjworh /tɥoɽ/

という宗教も存在し、これら6つは「？？？？世界の6大宗教」と呼ばれる。

歴史

世界史

連合帝国史

制作史

7/7/2023: Öphëtqa語から世界が派生しました。連合帝国等基礎設定ができました。
8/7/2023: 地方“薔城道”が生えました。連合帝国々教ほか世界宗教が生えました。Öphëtqa語の標準語としての地位に関する研究が公表されました。
10/7/2023: Tqöldöl教の教義戒律が増えました。気候への言及がありました。
11/7/2023: (まだコメントなし)

補遺
薔城道、一体どこの構成国にあるのだろうか。

[CLaKIS DNC 2302.0] (略称: )日本語題

佐藤陽花 — Mon, 06 Feb 2023 17:20:11 +0000

Draft Note for Comments Nr. 2302.0, CLaKIS, CL-KIITA.
Author. Haruka Sato. 著者名
Editor. ditto.　編集者名
Title.JA. DNCメタ文書仕様. 日本語題
Title.EN. Specification of DNC Meta Document. 英語題

本文

シャレイア語とトキポナ語数計度

佐藤陽花 — Sat, 04 Feb 2023 15:06:46 +0000

シャレイア語(2022年1月末)
Word: 2626 [word]
TWI: 21.88 [tp]
CTWI:197.34 [ctp]

シャレイア語(2023年2月頭)
Word: 3020 [word]
TWI: 25.17 [tp]
CTWI:200.84 [ctp]

前編　コーパス/コーパス言語学とは何か

佐藤陽花 — Sun, 18 Dec 2022 15:00:00 +0000

　人工言語創作アドカレ19日目の記事です。今回はコーパスについて取り上げようと思います。内容盛り盛りなのでシリーズ機能を使って前後編の二部構成でお送りします。

　なお本シリーズは元々ラヴェラ¹に出そうとしていた発表ポスターの稿をベースに執筆しているので、文体がやや硬い点はご容赦ください。

　昨日のすきともさんの記事、非常に興味深かったですね。私達²オレオレ辞書形式作者や人工言語のための情報技術・知識情報の研究開発・標準化関係者にとって、容易に新たな形式を試せるサンドボックスソフトの出現は非常に朗報だと思います(このすきともさん自身もこの分野の人なのですがねまぁ)。

後編⇨

コーパス・コーパス言語学とは

　さて、本題に入っていくこととしましょうか。皆さんの中には、「コーパス」という言葉は聞いたことあるけど、それが(具体的に)どんなものなのか知らない、という人が多いのではないでしょうか。そのような読者の皆さんのためにも、まずはコーパスやコーパス言語学とは何か、ということについて紐解いていきましょう。

　コーパス言語学は、(言語について究明する学問である)言語学を構成する一分野で、「コーパス」を利用して言語を分析・記述する学問領域です(Saito98, p.3)。

　では、この「コーパス」とは何でしょうか？The Oxford English Dictionary(OED)には'the body of written or spoken natural upon which linguistic analysis'(1956)とあり、「実際に(人々の間で)運用されている言語の定性的・定量的な分析・記述を行うための、言語運用の資料(言語テキスト)の集積」と言うことができます(Saito98, p.3-4)。

　インターネットが発達した現在では、「コーパス」と言えば専ら(コンピュータ上で処理可能な)電子的な言語テキストの集合体であることが殆どです。

コーパス言語学は、言語学の中で、次のような3つの特徴を持っています(Saito98, p.4)(Leech92)。

言語能力(言語認知や言語習得)よりも言語運用に重点を置いている
言語の普遍的特性よりも実証的な分析に重点を置いている
言語モデル³の構築において、言語の性質だけでなく数量にも重点を置いている

このようにコーパス言語学は、生成文法とは対照的な立場にある分野ではあります。

コーパスの特性と種類

　では、コーパスというものが具体的にどのようなものであるかを見ていきましょう。

コーパスの質と量

　まず、コーパスの特性について考えてみます。上でも説明した通り、コーパスの主目的として言語を定性的定量的に分析するというものがあります。分析するということは、特定の観点に基づいて総覧したり比較したりするわけですが、ここでその観点に基づいて分類されたテキストが、それぞれの分類を代表しているという前提を置く必要があります。この特性を「代表性」と呼びます。

　代表性を達成するには、テキスト量を増やすことのほか、分析対象以外の観点での分類によるテキスト収集のバランスをとり質を高めるなどの方法があります。

コーパスの種類

　コーパスは、サンプル量や目的、時代、伝達手段などによって分類することができます。これらの分類の違いによってどんな言語テキストを蒐集するか、コーパスデザインをどのようにするかなどが変わってきます。

サンプルコーパスとモニターコーパス

　テキストを一定量収集したのち以後変化させないコーパスをサンプルコーパスといい、また常に変化する言語を監視し、古いものを捨て新しいものを加えるコーパスをモニターコーパスと呼びます。

汎用コーパスと特殊目的コーパス

　汎用に編纂されたコーパスのほか、特殊目的コーパスとして、特定の年齢層や地域、分野に特化したコーパスや、言語学習のために編纂された学習者コーパスや、複数言語の比較のために編纂されたパラレルコーパスなどがあります。

共時コーパスと通時コーパス

　時代による分類では、蒐集するサンプルを同時代に限った共時コーパスと、複数の時代区分を設け時代ごとの違いを見る通時コーパスに分けられます。

文字言語コーパスと音声言語コーパス

　また伝達手段によって、書き言葉のみを収集した文字言語コーパス、話し言葉のみを収集した音声言語コーパス、そしてそれら双方を共に収集したコーパスなどに分けられます。

その他の種類

　そのほか、個別のコンピュータ上にデータを置くオフラインコーパスとサーバにデータを置きインターネットを通じてアクセスするオンラインコーパスなどの区別があります。

コーパスデザイン

　次に、代表的なコーパスがどのようなデザインによって収集・整理されているか見てみましょう。多くのコーパスでは、数百テキスト100万語から大規模なもので数千テキスト1億語のサンプルが、単一観点十数カテゴリ、ないし複数観点総計数十カテゴリに分けられて収められています。

　カテゴリは、小説・教育・報道・ビジネス・日常会話といった分野や、テキストの出所(メディアの種類)、発話年月、話者の年齢・社会階層・性別・地域などといった属性、話者の数・準備有無・話者間の関係といった話の形式によって分類されていることが多いです。このことは、ジョキのような観点で分析サれることが多いということでもあります。

コーパスの付帯情報

　付帯情報には、テキストの出典や発話状況などのサンプルに関する情報、話者交代や重なり、強調、取り消しといった文脈的な情報、品詞や統語構造などの言語的な情報があります。また、話し言葉ではイントネーションやポーズといった韻律特性にまつわる情報も含まれます。このような情報を付加させることを情報付与(アノテーション, annotation)、タグ付けといいます。

コーパスの記述形式

コーパスが生まれた初期の頃はテキストを平文(plain text, raw text)で集積していましたが、それでは分析に不便だということで次第に参照情報・メタ情報・文法情報などの付帯情報をタグ付けするようになります。これがコーパス記述形式の萌芽で、初期の形式には一行の最大桁数を決め冒頭の固定桁数にテキスト付帯情報を示す固定長形式や、COCOAというコーパス処理ソフトウェアが使用していたデファクトであるCOCOA形式などがあります。COCOA形式は矢括弧内に付帯情報(付帯情報の種類と内容)を収めテキストのヘッダ部に配置する形式です。

　その後、SGMLやXMLなどのマークアップ言語を用いた、標準化志向の記述形式が現れてきます。SGMLを応用したTEI(Text Encoding Initiative)による形式やCDIF(Corpus Document Interchange Format)、XMLに基づいたXCES(Corpus Encrding Standard for XML)(EAGLES(Expert Advisory Group on Language Engineering Standards)が開発した形式群の一つ)などが挙げられます。

　現代では、JSONやYAMLなどの類の形式を用いることとなると思います。

コーパスの編纂

　ここでは、タグ付けされた電子コーパスの編纂手順についてざっと追っていきます。

　まず、事前準備として、電子テキスト形式でないサンプルは、OCRや文字起こしなどで電子テキストにします。

　タグ付けではまず第一に品詞をタグ付けし、ついで活用曲用を見出し語となる代表形に直し(このとき、活用曲用の情報もタグ付けしておくと良いでしょう)、それをもとに構文解析していきます。

　品詞のタグ付けは、辞書を引きつつその語に有り得る全ての品詞をつけます。タグ付けプログラムは、文法規則に基づくタガーと確率論に基づくタガーに大別されます。

こうして得られた情報やテキストを特定の形式のもとに記録していくことでコーパスが完成します。

コーパスの関連分野

コーパスと辞書用例

　先程「コーパスの編纂」章で言及した通りタグ付けにおいて辞書を利用するほか、コーパスに基づいて辞書中の各見出し語における用例部分の生成を行うということもできる。ここで、コーパスのバランスや客観性に気をつける必要があります。

コーパスを用いた言語学習

　言語学習において、辞書の用例からコンコーダンスとして間接的にコーパスを用いるほか、「コーパスの種類」節で示した通り、特殊目的コーパスという分類の中に含まれる学習者コーパスというものがあり、それを言語学習に用いることができる。これは、言語学習者が発話・作文したものを収集したコーパスで、これを解析することにより学習者が陥りがちな誤りを発見することが出来ます。

参考文献

[Saito98]：齋藤俊雄 et al.『英語コーパス言語学　基礎と実践』、改訂新版、(1998年3月21日初版　2005年2月10日改訂新版、研究社)
[Leech92]：Leech, G.『Corpora and Theories of Linguistic Performance』、(1992年、J. Svartvik)

半年毎に開催されている人工言語・架空世界創作者の祭典「IWCC」内の企画内企画 ↩
主語デカすぎ問題 ↩
言語モデル：言葉や言語表現の法則を、その統語構造や出現確率、相互関係などに基づいて整理し表現したもの ↩

最近記事を投稿しておらんなぁ

佐藤陽花 — Fri, 18 Nov 2022 14:39:52 +0000

まあ投稿に至ってない下書きは幾つかあるが。
あと最初の頃は結構コンスタントに記事執筆してたのに....

Migdal: 佐藤陽花

CLAコードの改めての紹介と、現況＆今後の展望

はじめに

CLAコード - Conlang Layered Assignment

CLAコードの概説

CL-KIITA: 人工言語知識情報・情報技術事業体 フォロー

CL-KIITA: 人工言語知識情報・情報技術事業体 · GitHub

コード仕様概略

申請の方法と手続

審査チームについて

手動発行体制の報告と経緯

CL-KIITA / Temp_CLIR

Temporary System of Conlang Assignment Management Table

Temp CLIR

Included Packages

手動発行体制の手続

CLAコード一覧(2023-12-25)

みかぶる ・ ’23年12月24日

CLIR Assignment Management Table

さいごに

ようやく此処でLIISコード対応が実装されたので、事(LIISコード提案)の発端の記事の設定(言語名)をLIISコードにて設定さるよう修正してみた

ここ使ってくれる人が増えて色々な言語の紹介記事が流れて来て良いなあ。皆の言語で書かれた記事も見てみたい

LIISコードのIETFシステム対応化についてとイスクイルのLIISコード発給の告示

はじめに

LIISコード：言語情報交換補充コードの提案

佐藤陽花 が CL-KIITA: 人工言語知識情報・情報技術事業体 へ執筆 ・ ’22年2月23日

規格仕様の補遺

LIISコードのIETFシステム対応化について

イスクイルのLIISコード発給の告示

Cotec: Conlang Table Expression powered by CSV 【CLaKIS RFC】

諸元

仕様 (RFC)

拡張仕様: 概要、経緯及び更新情報の記載のための追加メタセル (コード1)

拡張仕様: 言語別ラベルレンダリングのための補助テーブル (コード2)

懸案事項

上載仕様: 日本語圏人工言語リストにおけるCotecのラベル及び型に関する定義

我正在做的多少人工語言簡介(和CLA碼近況)

外語(Oinarшalm語)

為了未知語言破解小組的多少語言

CLA號碼的近況

Migdalの正式始動に寄せて - 原典引照版

Migdalの正式始動に寄せて (原典引照版本文)

コメントに応じて変化する世界

ルール

コメントに応じて変化する言語

ンソピハ が Öphëtqa言語＆世界(仮称) へ執筆 ・ 7月5日 ・ 約 8400 字/語

世界

国家と地方区分

？？？？連合帝国

自然地理

プレート

気候

土壌

植生

社会地理

交通

社会

民族

言語

宗教

Tqöldöl教

他の宗教

歴史

世界史

連合帝国史

制作史

補遺

[CLaKIS DNC 2302.0] (略称: )日本語題

シャレイア語とトキポナ語数計度

前編 コーパス/コーパス言語学とは何か

コーパス・コーパス言語学とは

コーパスの特性と種類

コーパスの質と量

コーパスの種類

サンプルコーパスとモニターコーパス

汎用コーパスと特殊目的コーパス

共時コーパスと通時コーパス

文字言語コーパスと音声言語コーパス

その他の種類

コーパスデザイン

CL-KIITA: 人工言語知識情報・情報技術事業体フォロー

みかぶる・ ’23年12月24日

佐藤陽花が CL-KIITA: 人工言語知識情報・情報技術事業体へ執筆・ ’22年2月23日

拡張仕様: 概要、経緯及び更新情報の記載のための追加メタセル　(コード1)

Migdalの正式始動に寄せて　(原典引照版本文)

ンソピハが Öphëtqa言語＆世界(仮称) へ執筆・ 7月5日・約 8400 字/語

前編　コーパス/コーパス言語学とは何か