Recent Changes

2016-10-16
2016-05-31
2015-11-02
2014-04-16
2014-03-10
2013-12-17

Latest File Release

SMART-GS (0.10.1)2016-05-22 23:30

Wiki Guide

Side Bar

ミーティングの議事録も兼ねています。

2013.11.08.

・翻刻の変更履歴 … revisionの管理!

・version間のリンク?

・今までに読めていなかった部分の読み進め

・訳語のメモを付けるTEIタグ? → <note>でなく、同時に表示されるようなものは?

・挿入行のマークアップをTEIで

・アイデアは随時反映させるのではなく、まとめておいて後で実装する方向

2013.11.11.

全体として、TEIの方法論(アルキビスト向け)とSMART-GSの方法論にズレがあり、TEIはそのままではSMARTに応用することが難しい? →TEIコアパーツ(globals)を組み合わせて、1から作っていく方向?

・翻刻の変更履歴… revisionの管理?     TEIヘッダは改変を記録するためのタグを含む。

    ・ <change> (p.840) … 原史料に加えられた改変の記録を想定→進行中の翻刻作業でのような頻繁なものは向かない?
使用例 

    <profileDesc>
        <creation>
            <listChange ordered = "true">
                <change xml:id = "CHG-1"> First stage, written in ink by a writer </change>
                <change xml:id = "CHG-2"> Second stage, written in Goethe's hand using pencil </change>
                <change xml:id = "CHG-3"> Fixation of the revised passages and further revisions by Goethe using ink </change>
            </listChange>
        </creation>
    </profileDesc>

    参考: <revisionDesc> (p.1297) … 書類の改訂履歴を管理

        <recordHist> (p.1268) … 原史料および写本翻刻の改訂(版)状況を記述

・挿入行のマークアップ

    <add> … 挿入ないし書き込みの記述であることを示す。

2013.12.02.

前回のまとめ  ・汎用性 vs 時間的制約
 …前者を(ある程度)切って、史料翻刻に特化する方向で機能を具体化していく

 ・マークアップのタイミング
 …最初から「SMART-GS-TEI」とでも呼ぶべき形式で記述してゆく
 →Simply HTMLを用いてユーザからはマークアップの実態が不可視のまま作業できるようにする
 →あらかじめマークアップの「鋳型」を準備しておく(※翻刻に特化したもの)

 ・注意点
 1: 史料中のリンク構造をうまく乗せること
 2: SMART-GSの特性(行構造など)を反映してXMLを拡張する

今回の論点
・リンクの取り扱い
TEIをリソースでラップする

リンクのコピー時にURIが二重にできる?
→新たなURIを発行するとともに、コピー元のURIもcopyOf属性のようなものに記録か

smart特有のエレメント → そのままリソースとしてidを持つ
tei → TEIタグをSMARTのリソースで外側から囲む(ラップする)かどうか選択する機能

TEIの文法を変えずに整合性をとること

・既存のTEIドキュメントのSMART-GSへの取り込み?
→これをやり始めると考えうるすべてのTEIタグを考慮しなくてはならなくなる
→TEIをどうしても使いたい人が書き直すようにする?

2013.12.09.

・大浦さん

SimplyHTMLにて、HTMLのtree構造表示機能

・<br>は使えない→<zone>と<line>か? …ちょっと見苦しい?

・カーソルのデザイン考える

課題: 行のタグ、括るカーソルのデザイン、<a>にかわるもの、の案を作っておくこと

2013.12.16.

☆課題:XML、TEIにおける行(ws,linefeeder,...)の問題について詳しく調べる
将来、”TEIのためのSMART”というものが必要となるときに備えられるか。
特に、TEIのソースを直接ユーザがいじる段階にはどのように対策するか、できるか。

・行の問題…重要、熟議を要する
XMLとTEIの仕様の矛盾に起因する問題

サーチにおける行、TEIテキスト上の行、人間が認識する行、の兼ね合い
→サーチのためにぶつ切りになるようなイレギュラーな段組みは、リストを用いて行にまとめる?

・TEI上では<lb/>で「単なる文字を置く」ようにして行を管理するのが妥当?

・行をまたいだマークアップはどうするか。その編集に対しては?

・挿入に対する行番号については?

2013.12.24.

2014.1.6.

"Simply XML"(とも呼ぶべきもの)の作業方針について
 ○とりあえず(貧弱でも)DOMのパーサで
 ○img:text間対応のための独自の定義をのせる
 ○SMART用のCSSも?
 ○メインはlineとresourceをどうするか

・ファイルシステムvsJ-treeなど、windowsのファイルシステムとの絡みで煩雑化していたパスの修正難題→林先生が設計

2014.1.20.


林先生によるSG Moduleのタグ案
以下の三つのみに集約する:
<sg:l /> : 行のタグ。end属性のブール値で行開始位置と終了位置とを識別。
<sg:r /> : リソースのタグ。リソースの前に置き、あとに位置する要素をSMART-GSのリソースとする。
<sg:gt> : その他一般のマークアップを担うタグ(いまは<a>が担っているもの)。tagid属性の値で種類を指定。

※空エレメントとすることで、タグで括ると新たな個エレメントとなりtree構造が変化してしまい、diffとの整合が悪い問題を解消

・課題
(XMLとしての)TEIにおけるcontentに対する制約のようすについて調べ、上記SG Moduleとの整合をとれるようにする

2014.1.27.


「TEI化」という認識の改め
spread全体をTEIにする必要?→大幅な転換
gsx⇔TEI いまSMARTが持っている機能をTEIに「翻訳」する方向へ
使用するModuleを指定する機能は必須か
GUIとの連携がポイントとなる?
「どこまでやるのか?」を早い段階で見極める必要がある…GUIの「表示」に関することは進めていき、XMLエディタとしての仕様はしっかり検討する
(たとえば、色付き括弧の表示はwell-formednessの話なのでOK / 画像をどうするか?はvalidationの話なので要検討)
☆SMARTのspread treeの設計の見直し?
・Link構造の移植が難関か?(HTMLへの落とし込みまで視野に入れると…)
・ディレクトリ構造をTEIとして表現(移植)できるか?


2014.2.3.


大浦さん
(見た目は変わっていない)
メニューの項目を、(プリセットでなく)ファイルを読み込む形に合わせ変更(エディット機能)

橋本さん
翻刻の一括置換機能を改善(Back/Nextでページの切り替え; Replace可能に)
置換前のものが上書きされて見えなくなるので見づらい?→インターフェイスの改善

久木田さん
XMLunitの導入
commitの衝突に関する問題が残る
属性でなく<source>エレメントとして分ける

秋田
nodeエレメントとarcエレメント:arcは@fromと@toにnodeのidをとる
arcを使うにはnodeで包む必要

林先生
gsx再設計について
Elements available in All TEI Documents 最低限のセットからとりあえず組み始める

<link>エレメントと<ptr>エレメント→P5ガイドライン16.1.1

target = “#id1 #id2”は方向性がない…リンクのtraverseがむつかしい

SMARTのリンクはnavigation(方向性あり) source:targetの対

SMARTはリソースがあれば(場所を定義することなく)リンクをはれるが、TEIのptr/linkはひとつエレメントを作ってリンク(connection)を張る構造…合うかどうか?

多重リンクの扱い…SMART: spread内のconnectionを一カ所にまとめてある

長持ちするデザインを作るよう慎重に決定してゆく

SMARTの課題:TEIのオブジェクト化?→<node>で出来る?

例:画像マークアップをひとつの<node>として切り出す

TEIのタグをSMARTがどれだけサポートするべきかは中長期的な課題、吟味する


2014.3.3.


gsxファイルのTEI化の指針 ・SMART-GSのTEI化の目的:
1.TEIで定義されている豊富なテキストマークアップ用のタグを導入し、SMART-GSのテキスト表現能力を向上させること。
2.将来的にはSMART-GSをGUIリッチなTEI文書エディタとして利用できるようにするための下地を作ること。
・SMART-GSノTEI化の目的を達成するために技術的に達成すべきこと
1.文法に関してはXML化であり、その上で、
2.TEIに属するXMLのスキーマの、GUIなどによる編集や表示などのサポートを提供すること。
・具体的には…
TEI-validな文書を内包するXML文書になるように設計
SMART-GS manualに定義されている「テキスト」はすべてXML-validとなるように。

SMARG-GSモジュール(独自タグ)について ・名前空間sg:を確保してモジュールを導入
・<sg:connection>など、SMART-GSがすでに持つタグを表現するタグを導入。
・<sg:resource />によってリソース化を表現する。

メモ:文書の単位は何か?
「ページの順序は不確か。1ページ、1枚といった物理的文節は確か」→ページごとに1文書(ファイル)とする?
メモ:一般のXML editorへの展開をにらむ