空間のオブジェクトモデリングについて
-
- いいね！0
Oguchi T／小口 高
@ogugeo
地図を作るために現実を抽象化・写像化する過程は，1）実世界をentity（個別物体）に分解，2）entityをfeature（類型）として整理，3）featureをobject（シンボル）として表現，と記されることがある．GIScience系の人が好む考え．
2010-08-01 19:13:04
Masaki Ito
@niyalist
ソフトウェア工学で「オブジェクト指向モデリング」というのと同じように感じます．ソフトウェアにおけるオブジェクトは，性質だけでなく機能を持ち，メッセージ交換しお互いの性質を変化させながら相互作用するのですが． RT @ogugeo: 地図を作るために現実を抽象化・写像化する過程
2010-08-01 20:06:29
Masaki Ito
@niyalist
.@ogugeo ただソフトウェアの場合，対象を写しとる際の正確さ，精度とかよりも動くことが重要で，正確な（つまり複雑だったり過度に一般化されてたりする）モデルが作るうちにそぎ落とされたりします．余談ですがGeoToolsというソフトウェアはこの点で複雑すぎるな，と感じます．
2010-08-01 20:12:11
Masaki Ito
@niyalist
.@ogugeo 私のオブジェクトモデリングの技術不足ではあるんですが，対象の静的なスナップショットを表現するにはオブジェクト指向はよいけれど，ソフトウェアに動きを与えるには，ちょっと別の発想が必要かな，と思ってます．うまく言い表せないんですが．．．
2010-08-01 20:15:26
hfu
@_hfu_
@niyalist GeoTools をソフトウェア工学的に批判する作業をされるようなことがあれば、助太刀したいです。言いたいことがかなりある :-) おかげで pragmatic に目覚めた恩もある気がしますけど。
2010-08-01 21:53:33
Masaki Ito
@niyalist
@_hfu_ GeoToolsは，オブジェクト指向を習いたての人がやたらに継承とか使いまくって悦に浸ってる感じがありますよね．以前，ほんの一部をiPhone向けにObjective-Cに移植しようとしてうんざりしてやめました． @_hfu_ さんのご意見も聞きたいところです．
2010-08-01 22:37:57
Oguchi T／小口 高
@ogugeo
.@niyalist オブジェクトの語は共通ですが，オブジェクト思考との関係は想定外でした．僕が手続き型の言語しか学んでいないためでしょう．基本的な思考法に高い普遍性があることになりますね．GISでのこの考えは90年代初頭からと思います．オブジェクト思考の普及と合いそうです．
2010-08-01 23:21:02
hfu
@_hfu_
僕の言葉じゃない。繰り返す。僕の言葉じゃない。 :-) RT @niyalist @_hfu_ GeoToolsは，オブジェクト指向を習いたての人がやたらに継承とか使いまくって悦に浸ってる感じ...一部をiPhone向けにObjective-Cに移植しようとしてうんざり
2010-08-01 23:30:09
Masaki Ito
@niyalist
.@ogugeo ソフトウェアって，最終的には非常にメカニカルな計算機の動作を制御するのだけれど，ちょっと抽象度を上げたところで，数学的なモデルで議論する人（チューリングとか）や自然言語に近い議論をする人（チョムスキーとか）もいるようです．どっちも私はよくわからないのですが．．
2010-08-02 00:00:26
Masaki Ito
@niyalist
.@_hfu_ GeoTools の設計，オブジェクト指向にこだわってるせいで，ちょっと固すぎるんですよね．ああいうライブラリ集があることは，GISの技術(一部だけど)のコモディティ化に貢献してるけれど，ちょっとしたアイディア，実装，機能を付け加える柔らかさが全くないのが残念．
2010-08-02 00:10:40
Oguchi T／小口 高
@ogugeo
.@niyalist 書かれていたように，プログラムは動くことが究極の要求なので，アプローチは何でも可ということでしょうか．ところで地理空間の抽象化とオブジェクト思考ですが，用語が共通でも，前者の手順自体は単純な手続き型に見えます．似て非なるものという印象もあるのですが．．．
2010-08-02 00:51:58
hfu
@_hfu_
GeoServer 使いに疎まれることや、改善しますと手を上げたと勘違いされることを恐れない @niyalist に痺れる :-) あれ Java 文化のバッドパートが出てると思います。だから、根は深い。
2010-08-02 01:04:20
Masaki Ito
@niyalist
.@ogugeo 本来連続してる世界を何か（つまりオブジェクト）を単位に切り取り，それ中心に概念を整理するというアイディアがオブジェクト指向（情報系では人の自然な認知だと信じてる）に見えます．手順2はまさに「クラス」の考え方です．手続きの記述がないと動かないのもプログラムと同じ．
2010-08-02 01:07:07
Masaki Ito
@niyalist
@_hfu_ GeoServer使い！最近けっこう流行ってるんですかね．Javaである性で余計にエンタープライズ領域に人もノウハウも閉じてしまわないか心配だったりします（自分はJava育ちですが）．ちなみにオブジェクトモデリングの話には，ここで書きにくい個人的背景が別途あります．
2010-08-02 01:15:22
Oguchi T／小口 高
@ogugeo
.@niyalist 僕はかつてCを学びかけた時に，これは相互作用の世界で，いちにのさんの流れでは進まないと思いました．そこで既知の手続き型言語との乖離を感じ，自分の専門に必須でもないので学ぶのをやめました．しかしそれは狭い見方だったようですね．ご教示感謝．ではおやすみです．
2010-08-02 01:31:05
hfu
@_hfu_
いろいろ考えたのですけど、この背景って何でしょうか？本業の知り合いを誤爆してしまう可能性がある、といったようなもの？Java&UMLの「清算」、前進には必要だけど種々難しい。 RT @niyalist オブジェクトモデリングの話には，ここで書きにくい個人的背景が別途あります．
2010-08-03 03:47:32
hfu
@_hfu_
【精度の低いツイート】元来、応用スキーマという用語はRDBMSかXMLSchamaでしか使われていなかった。地理情報で「応用スキーマ」という用語を使った瞬間において、あなたの思考はRDBMSとXMLに束縛される。「応用スキーマ」という名においてそれ以上を語ることは、効率的でない。
2010-08-03 03:59:52
hfu
@_hfu_
【精度の低いツイート】「応用スキーマ」という名において、それ以上のことが語りうるという文化が生まれたこと自体が、ITとGITec/GISci/測量の間に理解の溝があることを示唆している。ただし、代案が取って代わるのではなくて、クラスベースOOの行き過ぎが是正されるべき。
2010-08-03 04:02:25
hfu
@_hfu_
【精度の低いツィート】クラスベースオブジェクト指向のアンシャン・レジームは、UML, XML, Java によって構成される。これは、アンシャン・レジームであって、既に mainstream IT では変革された。IT の辺境としての GITec で存続しているに過ぎない。
2010-08-03 04:11:08
hfu
@_hfu_
【訂正】RDBMSで直接出てくるのは、概念スキーマ、内部スキーマ、外部スキーマだった。応用スキーマという概念が出てくるのは、「組み込みでない」基本型が色々と導入されるため、概念スキーマを内部で階層化する必要が生じたためであると思われる。地理情報以外で出てくることは非常に少ない。
2010-08-03 04:29:32
hfu
@_hfu_
結局：いくら厳密なスキーマをUMLやXMLSchemaで定義したとしても、データがスキーマに準拠しているかどうか確認するのはインスタンス単位でチェックすればよい。UMLやXMLSchemaは計算機には「よく理解できない」(!)。だったら、普通に言葉と表とコードで書けば良いことに。
2010-08-03 04:34:20
hfu
@_hfu_
結局：UMLとXMLSchemaの「処理系」がほとんど発生しなかったのが痛恨だったのだろうが、その原因は UML と XMLSchema がその方面でプラクティカルであろうという態度を持ち合わせていなかったところにある。
2010-08-03 04:37:39