Nukadoko 👉 ND-Index

これは完成稿ではない。現れる前の構文である。

ND-260817｜file ≠ function

object-firstからrelation-firstへ

発端：研究成果 公開・保存・流通 運用ポリシー策定

👉 研究成果 公開・保存・流通 運用ポリシー

Encounter

当初の問いは、

arXivか、Zenodoか。
研究成果を「どこに置くか」。

だった。

しかし、この問いでは媒体ごとの違いを一つの尺度で比較することになり、役割分担がうまく整理できなかった。

Academia.edu、個人サイト、Zenodo、aiXiv等を比較する過程で、問いそのものが変化した。

どこに置くか？

ではなく、

どのrelationを、どの媒体に担わせるか？

Exposure 01｜file ≠ function

同じPDFであっても、置かれる媒体とのrelationによって働きが異なる。

したがって、

file ≠ function

ファイルそのものがEncounterやArchiveという機能を内在的属性として持っているわけではない。

Exposure 02｜Function is Relational

今回の実践から、次の命題が露出した。

機能は物の属性ではない。関係の様態である。

Archiveはファイルの属性ではない。

ファイルが特定の保存・参照システムとのrelationに置かれることによって、Archiveとして働く。

Encounterも同様である。

研究成果が特定の公開・流通環境とのrelationに置かれることで、Encounterを生じさせる。

Exposure 03｜object-first → relation-first

当初の問いはobject-firstだった。

どのプラットフォームが、研究成果を置く「正しい場所」なのか。

問いをrelation-firstへ切り替えると、

Encounterを誰がsupportするか。
Structureを誰がsupportするか。
Archiveを誰がsupportするか。
Experimentを誰がsupportするか。

となる。

ここでは一つの媒体に複数の役割を集中させる必要がない。

研究成果は単一の場所に所属するobjectではなく、複数のrelationのなかで異なる働きをする。

Existing Traceとの共鳴

既存命題：

向きは関係の属性である。

今回の実践から露出した命題：

機能は物の属性ではない。関係の様態である。

両者は同じ構文を持つ可能性がある。

さらに検討候補：

Traceもまた、単独の物の属性ではなく、後続する何かとのrelationにおいてTraceとして働くのではないか。

Status：OPEN / NOT YET CLAIMED

Methodological Trace

今回の発見は、既存理論からPolicyを演繹した結果ではない。

実務的な問い、

「研究成果をどこに置くか」

を解こうとする過程で、object-firstな問いの限界が露出し、relation-firstへの転換が生じた。

その結果、既存のEgQE理論系列が別ルートで到達していたrelation的構文と再遭遇した。

したがって本件は、

実践先、理論後。

の一事例として保存する。

Working Syntax

Object → Placement

ではなく、

Object × Relation → Function

あるいは、さらに簡潔に、

Function emerges in relation.

Operational Footnote

Encounter層の終了条件：出会えれば仕事終了。

Status：NUKADOKO / OPEN

次回以降、SX・URL・TCその他の既存系列との構文的対応をre-Traceする。