規範的取得、管理與落實

國

立 政 治 大 學

‧

Na tiona

l Ch engchi University

位置則是使用 hasSQL 敘述透過何種方式能夠存取。Meta Data 的後續分類則由 各 TCD 各自決定。一條 Data Policy 描寫著一份或多份 Meta Data，而一條 Data Policy 具備一個 Condition，該 Condition 則是由不同的 Class 所組成，例如 DataUser、Action、Purpose，其中在 iTCD 中才會有 DataOwner 及 Meta Data 是因為 iTCD 並不知道 Request 會需要哪一些 Meta Data，因此必頇要將此情況 寫入 Condition 中；一條 Request 則是與 Data Policy 相同具有一個 Condition 組合，而分別用兩條 Property hasAccessCondition 與 hasHandlingCondition 分別表示兩種不同的 Condition，最後一條 Data Policy 與 Meta Data 都具備 hasNameSpace Property 是因為後續在進行 Policy Management 時必頇要了解一 條 Data Policy 或 Meta Data 所屬的 TCD 以便進行 Policy 的選擇。

4.3.2 規範的取得、管理與落實

當 TCD 對應到 iTCD 以及增加了 TisD 後，並且 Data Policy 如同上一節所示 被定義清楚後，前置作業才算完成。當有後續的使用者經由上層的 iTCD 輸入 Request 後，必頇把 Request 裡的元素與現有的 Data Policy 一一比對動作，這 主要分成三個步驟：取得、管理與落實。

4.3.2.1 規範取得

規範的取得(Policy Fetch)：當使用者輸入 Request 時，必定需要輸入需要 使用的從 iTCD MetaData 取得的資料分類，藉由此分類我們可以分別對應到 TCD 中 Meta Data 的分類，將這些 Meta Data 找到，並且利用 Property"describes"

可以找到敘述這些 Meta Data 的 Data Policy，然而這些存在 TCD 中的 Data Policy 所含有的 Condition 組合詞彙乃是採用原有 TCD 中各個 Class 的分類詞彙，因此 必頇將取得的 Data Policy 中的 Condition 詞彙同樣透過對應的方式轉換到上層 iTCD 所整合的詞彙中。在上層詞彙對應成下層詞彙時，因為對應的方式是 LAV，

‧ 國

立 政 治 大 學

‧

Na tiona

l Ch engchi University

轉換的方式如同上一章所示；相反的，當下層詞彙對應成上層詞彙時，對應方式 剛好反過來，會變成 GAV 的對應方式，所以在轉換方始只需要採用 Unfolding 的方式即可。需要將滿足條件的 Meta Data 及 Data Policy 全部送回 iTCD 的原 因在於，當 TCD 在整合時會碰到重複性的資料存在，而重複性的資料極有可能是 兩家機構共同所擁有的，因此才會產生 TisD 描寫共同資料的規範，換句話說將 Data Policy 送回 iTCD 的原因也在於必頇讓 iTCD 判斷是否有出現 TisD 的情形，

以選擇符合的 Data Policy 執行。本研究將使用 DL-Expression 作為 Meta Data 與 Data Policy 的取得方式，取得方式如下：

𝐹𝑒𝑡𝑐𝑕𝐷𝑎𝑡𝑎 ≡ 𝐼𝑛𝑝𝑢𝑡𝐷𝑎𝑡𝑎𝐶𝑙𝑎𝑠𝑠

𝐹𝑒𝑡𝑐𝑕𝑃𝑜𝑙𝑖𝑐𝑦 ≡ 𝐷𝑎𝑡𝑎 𝑃𝑜𝑙𝑖𝑐𝑦 ⊓ ∃𝑑𝑒𝑠𝑐𝑟𝑖𝑏𝑒. 𝐹𝑒𝑡𝑐𝑕𝐷𝑎𝑡𝑎

第一條 DL-Expression 表示從 Request 中找出屬於 Meta Data Class 的 Instance 之所在 Class 當作 InputDataClass，因為在先前的對應中已經事先對 應了 InputDataClass 在 TCD 中分別對應的 Class，在此不需要輸入對應的 Class，

而是會推論出下層哪一些 Class 是對應到 InputDataClass。第二條

DL-Expression 則是從取得的 MetaData 中找出 Data Policy 是描述這些 Meta Data 的。

4.3.2.2 規範管理

當規範取得後，iTCD 必頇判斷是否存在同一份資料卻有多個 TCD 中 Data Policy 描寫，在此分成兩種情況，一為資料擁有者因為方便起見，刻意將存在 同一個地方的同一筆資料給數個 TCD 使用，因此 TCD 並不知道該資料是與其他 TCD 具有重複性質的；換句話說 TCD 也不需要遵守其他 TCD 的規範，因此在規範 管理上不需要處理此情況。另一種情形是 TCD 之間彼此事先知道重複的資料部分，

並且使用 TisD 將共同資料的部分額外規範，但是各個 TCD 間仍會有各自的 Data Policy 描寫同一份資料的情形。例如 TCD 內部可能規定某重複資料可以被讀取，

‧ 國

立 政 治 大 學

‧

Na tiona

l Ch engchi University

為了醫院的營運或是學術分析等目的；而 TisD 則規範範圍更廣，如允許在兩家 醫院同時診療的情況下對病歷資料進行增修等動作，當然 TCD 原有的 Data Policy 也會囊括之。在此步驟中對規範管理的概念為：”若重複資料的 Meta Data 中，其中有一份 Meta Data 來自 TisD 則就選用 TisD 所描寫的規範，否則不予處 理”。表達方式如下：

𝑝𝑜𝑙𝑖𝑐𝑦 𝑜 𝑕𝑎𝑠𝑁𝑎𝑚𝑒𝑆𝑝𝑎𝑐𝑒 𝑜 𝑖𝑛𝑣𝑒𝑟𝑠𝑒(𝑕𝑎𝑠𝑁𝑎𝑚𝑒𝑆𝑝𝑎𝑐𝑒) 𝑜 𝑡𝑐𝑑

≡ 𝑏𝑒𝑙𝑜𝑛𝑔𝑠𝑇𝑜𝑇𝐶𝐷

𝑑𝑒𝑠𝑐𝑟𝑖𝑏𝑒𝑠 𝑜 𝑕𝑎𝑠𝑆𝑄𝐿 𝑜 𝑖𝑛𝑣𝑒𝑟𝑠𝑒(𝑕𝑎𝑠𝑆𝑄𝐿)𝑜 𝑖𝑛𝑣𝑒𝑟𝑠𝑒(𝑑𝑒𝑠𝑐𝑟𝑖𝑏𝑒𝑠)

≡ 𝑛𝑒𝑒𝑑𝑇𝑜𝑀𝑎𝑛𝑎𝑔𝑒𝑚𝑒𝑛𝑡

FetchPolicy ⊓ not(∃needToManagement. (∃belongsToTCD. TisD))

⊔ ∃belongsToTCD. (not TisD) ≡ EnforcePolicy

前面兩條表達方式是採用 OWL2 裡的 Property Chain，o 代表 Property 與 Property 之間的連接。第一條 Property Chain 是找到每一條 Data Policy 所屬 的 TCD，由於 TCD Class 只會在 iTCD 中出現，因此必頇在此時決定好。第二條 則是同樣透過 Property Chain 找出那些 Policy 所描寫的 Meta Data 是具有重複 性質的。第三條 DL-Expression 則表示從第二條所找出的 Policy 中，有哪一些 所屬的 TCD 是不為 TisD 的，並且該 Policy 也沒有與屬於 TisD 的 Policy 有第二 條 Property Chain 所產生的關係。將這些找出來後不要，剩下的就是準備執行 的 Data Policy 了。可以使用邏輯表示成(FetchPolicy − Policy belongsTo TCD) ∪ TisD Policy如下圖 7 所示：

‧ 國

立 政 治 大 學

‧

Na tiona

l Ch engchi University

n eed ToMan g em en t Fetch Policy

Policy b elon g tTo TCD TisD Policy Not

Need ToMan g em en t

圖 7 Fetch Policy 概念圖

上述的 DL-Expression 是建立在 Close Assumption 當中，也就是當一個元 素不存在於一個集合中，則該元素不屬於該集合，但是在 OWL2 的假設當中卻剛 好相反，也就是當一個元素不存在於一個集合中，無法確定該元素是否屬於該集 合，除非明確地說出該元素不屬於該集合，稱為 Open Assumption，因此第三條 DL-Expression 無法正確的執行與 OWL2 上，本研究將先找出不符合的 Policy，

再利用 Host Language 手動式將允許的 Policy 放置在 Enforcement Class 中。

4.3.2.3 規範的落實

透過規範管理之後，得到的是需要被落實的規範，在此必頇先將 Request 進 行成兩類，一類為 Action 為 Get Class 之下的 Request，另一類則是 Action 為 Non-Get Class 之下的 Request，如果 Request 為 Get 則表示該 Request 除了需 要第一次的規範落實外，還必頇落實第二次 Data Handling 的規範，反之 Non-Get Request 則只需要一次規範落實即可。規範落實是先找到每一條 Policy 中

ConditionInstance 所存在的 Class，利用該 Class 作為一個 Condition 落實的 條件，例如範例 1 如果成為頇被落實的 Data Policy，即可表示成為：

‧

因此，不同的 Data Policy 會被置換成不同的 DL-Expression，不同點僅在於

𝑕𝑎𝑠𝐴𝑐𝑐𝑒𝑠𝑠𝐶𝑜𝑛𝑑𝑖𝑡𝑖𝑜𝑛中的𝑕𝑎𝑠𝑃𝑎𝑟𝑡𝑂𝑓組合，在此先行將上述的 DL-Expression 表 示成

上述兩條 DL-Expression 先個別將兩種不同的 Request 分類後分開處理，若為 𝑁𝑜𝑛𝐺𝑒𝑡𝑅𝑒𝑞𝑢𝑒𝑠𝑡只需要執行第三條 DL-Expression 類型即可，反之則除了第一次 的 AccessCondition 需要比較外，HandlingCondition 還需要額外比較。

‧ 國

立 政 治 大 學

‧

Na tiona

l Ch engchi University