Business Process Context:

(1)

第三章 XML 原生資料庫查詢之規劃

本研究是透過利用 XML 原生資料庫(eXist)這個資料庫，來儲存 ebXML 開放性電子商務標準相關規格的 XML 檔案，並且使用 OWL 與 RDF 這二種文件，做電子商務標準規格的搜尋工作之結果研究。

在利用 RDF 與 OWL 作查詢的過程中，本研究透過建構出電子商務核心組件的 XML 檔案，進行文件語意的分析，利用具有鑑別力的字彙進行文件的擷取，以期望達到較精確的查詢結果，避免使用者要在做一次篩選的工作。像商業核心文件這樣的文件，如何儲存及達到精確的搜尋，是很重要的課題。本章將分為以下的部份探討:

1. Native XML 資料庫與 RDF/OWL 之結合。

2. 利用 XQuery 語法在 Native XML 資料庫之查詢。

3. Context Search。

4. Federation Search。

第一節 Native XML 資料庫與 RDF/OWL 之結合

本節規劃的流程可以分為三大模組:(1)檔案轉換(Converter) (2) 檔案儲存 (3)檔案 index 查詢。

3.1.1 檔案轉換

轉換檔案部份，利用 UN/CEFACT 所提供的工作試算表(Excel)所儲存整理的檔案，其內容包含了核心組件(Core Components)的所有物件類別，有 ACC、BCC、

ASCC、ABIE、BBIE、ASBIE 與 DT，本研究採用即是 CCL07B 版，UN/CEFACT 釋出的版本如下圖:

(2)

圖 3.1 Core Component Library 07B(CCL07B)之工作試算表

利用 UN/CEFACT 所定義的物件類別，我們將其轉換成一個個的 XML 檔案，將核心組件(Core Components)存入 eXist 資料庫中，進行核心組件的管理，實作查詢系統。下圖為轉換的檔案形式:

<?xml version="1.0" encoding="big5"?>

<CCL07B_ACC>

<DictionaryEntryNameDEN>Financial Account. Identification. Identifier</DictionaryEntryNameDEN>

<Definition>A unique identifier for this financial account.</Definition>

<ObjectClassTerm>Financial Account</ObjectClassTerm>

<PropertyTerm>Identification</PropertyTerm>

<RepresentationTerm>Identifier</RepresentationTerm>

<BusinessTerms>Account Number</BusinessTerms>

<OccurrenceMax>unbounded</OccurrenceMax>

</CoreComponent>

</CCL07B_ACC>

程式碼 3.1 轉換的核心組件 XML 檔案

(3)

3.1.2 檔案儲存

當我們將核心組件轉成 XML 檔案之後，就將 XML 檔案匯入到 XML 的原生資料庫(eXIst)中，以下程式碼為 eXist 本身所提供的 Java API，可讓使用者直接撰寫程式匯入:

public class StoreFile {

public final static String URI = "xmldb:exist://localhost:8080/exist/xmlrpc";

public static void main(String args[]) throws Exception { if(args.length < 2) {

System.out.println("usage: StoreExample collection-path document");

System.exit(1); }

String collection = args[0], file = args[1];

// initialize driver

String driver = "org.exist.xmldb.DatabaseImpl";

Class cl = Class.forName(driver);

Database database = (Database)cl.newInstance();

DatabaseManager.registerDatabase(database);

// try to get collection Collection col =

DatabaseManager.getCollection(URI + collection);

if(col == null) {

// collection does not exist: get root collection and create // for simplicity, we assume that the new collection is a // direct child of the root collection, e.g. /db/test.

// the example will fail otherwise.

Collection root = DatabaseManager.getCollection(URI + "/db");

CollectionManagementService mgtService = (CollectionManagementService) root.getService("CollectionManagementService", "1.0");

col = mgtService.createCollection(collection.substring("/db".length()));

}

XMLResource document = (XMLResource)col.createResource(null, "XMLResource");

File f = new File(file);

if(!f.canRead()) {

System.out.println("cannot read file " + file);

return;

}

document.setContent(f);

System.out.print("storing document " + document.getId() + "...");

col.storeResource(document);

System.out.println("ok.");

}

程式碼 3.2 使用 XML:DB API 進行儲存 XML 檔案到 eXist 資料庫

(4)

3.1.3 檔案 index 查詢

當我們將核心組件的 XML 檔案，匯入 eXist 資料庫之後，我們就將所有核心組件中所有的物件類別，包含:均形成 OWL/BIE 中的物件類別形成一個 RDF 的文件，當作查詢時的 index。

BIE 的 RDF 格式:

<?xml version='1.0' encoding='UTF-8'?>

<!DOCTYPE rdf:RDF[<!ENTITY ntnu 'http://www.ice.ntnu.edu.tw/ntnu#'><!ENTITY rdf

'http://www.w3.org/1999/02/22-rdf-syntax-ns#'><!ENTITY rdfs 'http://www.w3.org/2000/01/rdf-schema#'>]>

<rdf:RDF xmlns:ntnu="&ntnu;" xmlns:rdf="&rdf;" xmlns:rdfs="&rdfs;">

<ntnu:RO rdf:about="&ntnu;UN01001290" ntnu:BusinessProcess="Trade" ntnu:Industry="In All Contexts"

ntnu:OfficialConstraints="In all Context" ntnu:Product="In All Contexts"

ntnu:RegionGeopolitical="None" ntnu:Role="In All Contexts"

ntnu:SupportingRole="In All Contexts" ntnu:SystemConstraints="In All Contexts"

rdfs:label="UN01001290"/>

<ntnu:RO rdf:about="&ntnu;UN01002071" ntnu:BusinessProcess="In All Contexts"

ntnu:Industry="In All Contexts" ntnu:OfficialConstraints="In all Context"

ntnu:Product="In All Contexts" ntnu:RegionGeopolitical="None"

ntnu:Role="In All Contexts" ntnu:SupportingRole="In All Contexts"

ntnu:SystemConstraints="In All Contexts" rdfs:label="UN01002071"/>

<ntnu:RO rdf:about="&ntnu;UN01001295" ntnu:BusinessProcess="Trade"

<ntnu:RO rdf:about="&ntnu;UN01000240" ntnu:BusinessProcess="In All Contexts"

程式碼 3.3 核心組件:RDF 格式

(5)

BIE 的 OWL 格式:

<?xml version="1.0"?>

<rdf:RDF xmlns="http://www.owl-ontologies.com/Ontology1209969875.owl#"

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

xmlns:owl="http://www.w3.org/2002/07/owl#"

xml:base="http://www.owl-ontologies.com/Ontology1209969875.owl">

<owl:Ontology rdf:about="BIE"/>

<owl:Class rdf:ID="FinancialInstitution"/>

<owl:Class rdf:ID="Document"/>

<owl:Class rdf:ID="Payment"/>

<owl:Class rdf:ID="CurrencyExchange"/>

<owl:Class rdf:ID="ExaminationResult"/>

<owl:Class rdf:ID="Organization"/>

<owl:Class rdf:ID="AllowanceCharge"/>

<owl:Class rdf:ID="Tax"/>

<owl:Class rdf:ID="Party"/>

<owl:Class rdf:ID="AccountingAccount"/>

<owl:Class rdf:ID="ContractChange"/>

<owl:Class rdf:ID="Period"/>

<owl:Class rdf:ID="WorkItem"/>

<owl:Class rdf:ID="Facility"/>

<owl:Class rdf:ID="Guarantee"/>

<owl:Class rdf:ID="Price"/>

<owl:Class rdf:ID="Delivery"/>

<owl:Class rdf:ID="MonetarySummation"/>

<owl:Class rdf:ID="Adjustment"/>

<owl:Class rdf:ID="Payment"/>

<owl:Class rdf:ID="Period"/>

<owl:Class rdf:ID="Registration"/>

<owl:Class rdf:ID="Country"/>

<owl:Class rdf:ID="PerformanceMeasurement"/>

………

程式碼 3.4 核心組件:OWL 格式

(6)

第二節利用 XQuery 語法在 Native XML 資料庫之查詢

資料查詢的主要功能是根據使用者輸入的字串，在資料庫中找出包含或匹配的字串內容，並且回傳相關文件，呈現給使用者有用的資訊。查詢功能的提供，

可以增加資料庫的使用效率，達到資料分享與交流的目的。

在本研究中，利用 eXist 作為儲存 ebXML 開放性電子商務標準相關規格的 XML 檔案，而利用本身資料庫中所支援的查詢語言，作為文件搜尋的語法，而此資料庫是支援 W3C 所提出的查詢語言規格:”XQuery”。

3.2.1 XQuery 簡介

XQuery 是一種功能強大和容易使用的 XML 資料查詢語言，如同關聯式資料庫提供的標準 SQL 查詢語言，XQuery 就是 XML 資料的查詢語言。XQuery 是由 W3C 的 XML Query 工作小組所開發和定義的一種查詢 XML 語言。XQuery 語言是一種強調型態(Strongly-typed)語言，其資料型態源於 XML Schema，它與 XPath 2.0 使用相同的資料模型。實際上，XQuery 是一種運算式語言，程式就是運算式集合，執行 XQuery 程式就是執行運算式集合，已產生出最後的運算結果。

XQuery 語言是一種路徑運算式(Path Expressions)、FLWOR 運算式(類似 SQL 語法)、條件運算式和 XQuery 函數所集合而成的。XQuery 語言的特點如下所示:

¾ 相容於其他 W3C 的規格。

¾ XQuery 語言可以查詢結構化和非結構化資料，使用獨立的通訊協定，

以方便在不同的系統中取得相同的查詢結果。

¾ 語言不只是一種強調型態的語言，不同於傳統程序式程式語言，XQ 類似 SQL 語言是一種宣告式的查詢語言。

¾ 語言支援多文件的合併查詢，可以輸出排序的查詢結果，並且可以將 XML 文件轉換輸出成 XHTML 文件，或其他 XML 文件。

(7)

¾ 可以修改輸出資料，新增 XML 元素或屬性。

3.2.2 XQuery 查詢語法

XQuery 語言並非使用 XML 語法，其基本規則，如下所示:

¾ XQuery 語言區分英文字母大小寫，Items、items 和 ITEMS 是不同的名稱，通常使用小寫的英文字母。

¾ XQuery 程式碼的元素、屬性、函數和變數名稱必須是合法的 XML 名稱，

可以加上名稱空間的字首。

資料型態:

XQuery 的基本資料型態和 XML Schema 內建資料型態相同，如下所示:

¾ 布林(Boolean)資料型態:布林值 true 或 false。

¾ 數字(Number)資料型態:包含整數和浮點數值。

¾ 字串(Strings)資料型態:使用單引號或雙引號括起的字元集合。

¾ 日期時間的資料型態:代表日期、時間和期間。

¾ XML 相關的資料型別:例如:QName 等資料型態。

變數與文字值:

在 XQuery 程式碼中使用的變數並不需事先宣告，而變數是以「$」符號開始的合法 XML 名稱。例如:一些 XQuery 變數範例，如下所示:

$x、$y、$name、$book

XQuery 的文字值(Literal Values)主要分為三種型態，如下所示:

字串(Strings):XQuery 的字串可以使用單引號或雙引號括起來的字元集合。例如:”資訊工程系”。

數字(Numbers):XQuery 的數字可以是整數或浮點數。例如:1、99.8。

建構型態:使用特殊建構的特殊型態。例如:日期

(8)

xs:date(“2008-05-09”)。

XQuery 選取與過濾元素一共有兩種方式，一種為路徑運算式，不過此方式過於簡單，因此只能選取元素或屬性而已；另一種則是使用 FLWOR 運算式，FLWOR 是一種功能更為強大的運算式。

FLWOR 運算式主要是由 for、let、where、order by 和 return 子句所組成，

五種子句類型如下所示:

¾ For 子句:可以將 in 指令後路徑運算式取得的順序，依序指定給前的變數，每次一個項目，直到順序的最後一個項目為止。

¾ Let 子句:用來指定 XQuery 變數的值，變數值可以是項目或順序。

¾ Where 子句:指定條件運算式來進一步過濾查詢結果，只有當運算式為 true 時，才執行 return 子句。

¾ Order by 子句:可以指定輸出結果的排序方式。除此之外，我們可以使用「,」符號指定多個排序方式。

¾ Return 子句:輸出查詢的結果，如果是使用路徑運算式，則就是輸出選取的節點內容。

我們可以藉由以下的例子，來說明 FLWOR 運算式的寫法，如下所示:

<? xml version=”1.0” encoding=”Big5” ?>

<author>Johnson</author>

</book>

<title>JAVASCRIPT</title>

</book>

(9)

<author>Kevin</author>

</book>

<title>Swing</title>

</book>

<author>Horatio</author>

</book>

</bookstore>

程式碼 3.5 XQuery:XML 檔案範例

XQuery 程式內容:

<db>

{

for $book in doc(“bookstore.xml”) /bookstore/book where $book/price > 500

order by $book/title return $book/title }

</db>

程式碼 3.6 XQuery: XQuery 語言

其程式回傳結果為:

<db>

<title>JAVASCRIPT</title>

<title>Swing</title>

</db>

程式碼 3.7 XQuery: XQuery 回傳結果

(10)

第三節 Context 與核心組件之關連

在本節中所要探討的是本研究中作為查詢範例的 ebXML 商業核心組件中的一些商業元件，因為這些商業元件的存在，使得我們的查詢功能可以達到準確結果，減少錯誤發生。

3.3.1 Context

在 CCTS version 3.0 Implementation Verification 當中，特別將 BIE 中的 Context 部分作為ㄧ個章節來討論。由此可知，Context 這個部份在 BIE 文件中，佔有相當重要地位。

Context 內容:

Business Context:商業文件中應該包含合適的文件種類，以便定義出唯一且有意義的商業文件。為了要確定此文件的唯一性，每一份商業文件會有下列的項目:

9 Unique Identifier(mandatory): 唯一且明白的確定商業文件。

9 Version Identifier(mandatory): 標示此商業文件的版本。

Context value:為了要清楚地且有規範地描述商業文件，因此，一份商業文件中，文件的種類欄位均有值。

敘述特殊的商業文件，每一商業文件的文件種類都會有相對應的值，來標示此商業文件。目前有八個已認可的文件種類，會有相對應的值。每一個文件值會有下列的特性:

9 Value(mandatory):描述特殊的文件。

9 Meaning(mandatory):文件值的意義。

(11)

文件種類是為了要讓使用者可以在不同商業文件中，定義且區分出唯一的文件。目前有八種文件類別，每一種的內文類別都利用標準的分類系統，提供相對應的值來對應不同的類別。以下分別詳述這些種類特性:

Business Process Context:

描述一個商業情況時，當中最重要的觀點就是此商業活動是如何的經營管理。Business Process Context 提供一個明確定義商業活動的方式。為了確定商業活動的一致性，在此利用 UN/CEFACT Catalogue of Common Business Processes 的標準來作為參考。

Product Classification Context:

描述商業情況的觀點，與商業情況相關的產品或服務，在商業過程中可以交換、操作運用或彼此相關的。Recognized Code lists 則提供了 product classification contexts 的資料。其 Recognized code lists 資料來源，則包含了以下出處:

9 Universal Standard Product and Service Specification (UNSPSC) – Custodian : GS1

9 Standard International Trade Classification (SITC Rev .3) – Custodian : United Nations Statistics Division (UNSD) 9 Harmonized Commodity Description and Coding System (HS)

– Custodian : World Customs Organization (WCO)

9 Classification Of the purposes of non Profit Institutions serving households (COPI) – Custodian : UNSD

(12)

Industry Classification Context:

敘述不同的企業單位或伴隨著商業過程中所產生的一些企業單位。Recognized Code lists 則提供了 product

classification contexts 的資料。其 Recognized code lists 資料來源，則包含了以下出處:

9 International Standard Industrial Classification (ISIC) – Custodian : UNSD

9 Universal Standard Product and Service Specification (UNSPSC) Top-level Segment[digits q and 2] used to define industry.

– Custodian : ECCMA

Geopolitical Context:

描述商業文件中與地區、民族或地域性的文化因素有所相關的。Geopolitical Context 中包含相關的大陸(continent)、經濟區域與國家。Geopolitical Context 使用下列所述的，當作資料:

9 Continent

9 Country-ISO 3166.1

9 Country Sub-entity – ISO 3166.2 9 Economic Region

9 Global

9 Multi lateral Organizations

Official Constraint Context:

敘述交易情況的觀點，這些交易情形來自於正當的及規則的，與相似的正式種類。Official Constraint Context 有兩個不同的部份:

9 Regulatory and Legislative : 單方面的，包含顧客權益規定。

9 Conventions and Treaties : 雙方面或多方面的協議，與 Regulatory and Legislative 不同。

(13)

Business Process Role Context:

說明在交易過程中，參與交易的單位。此種類的值是利用 UN/CEFACT Catalogue of Common Business Processes 所提供的資料作為參考。

Supporting Role Context:

在交易過程中，沒有實際參與交易的單位，但是對交易感興趣的單位。此種類的值是來自 UN/EDIFACT code list 中。

System Capability Context:

此類型描述在交易情況中，系統或標準當中的一個類別、系統的情況。此類型的值最少需要一對，一個是分類結構系統的定義，

一個是結構系統。

3.3.2 核心組件之關連

在這一小節當中，依據 CCTS version 3.0 Implementation Verification 文件中，所提及的 CC、BIE 與 DT 之間的相關性，之間的相關程度是非常錯綜複雜。雖然如此，不過在 CCTS version 3.0 當中，還是將其之間關係用以下示意圖可以說明。

(14)

圖 3.2 CC 與 BIE 之關係示意圖 ACC 與 ABIE 之關連:

在 CCL07B 工作試算表中，ACC 中的物件類別(Object Class Term)這個欄位中，所代表的是資訊系統內的資料物件名稱，具有特定概念的資料集，具有一定的重要的特性。所以 ACC 與 ABIE 之間的關係可以透過這一層的關係找出來，彼此之間相互連結。ABIE 中則因為有不同的物件類別修飾語(Object Class Term Qualifier)，造成多個 ABIE 的核心組件會對應到同一個 ACC 核心組件。

BCC 與 BBIE 之關係:

BCC 欄位中物件類別(Object Class Term)、屬性用語(Property Term)與表示用語(Representation Term)，呈現出 BCC 這個核心組件的主要特徵。因 BCC 擁有不同屬性用語與表示用語，造成一個 ACC 底下會有不同的 BCC。相同的型態也出現在 BBIE 中，因此一個 ABIE 底下會有多個 BBIE。而相對的，在 BBIE 中也因為有不同的物件類別修飾語，因此多個 BBIE 對應同一個 BCC。

(15)

圖 3.3 CC 與 BIE 之舉例關係說明圖

BBIE 與 qDT 之關係:

BBIE 的資料型別修飾語(Data Type Qualifier)與修飾語的資料型別 UID(Qualified Data Type UID)這兩個欄位，直接的說明 BBIE 與 qDT 兩者之間的關係。但因為 BBIE 是基本的資訊個體，因此會有不同的 BBIE 均使用相同的 qDT 的情況。在這樣的情況之下，使得多個不同的 BBIE 均用同一個 qDT。

圖 3.4 BBIE 與 DT 之關係圖

(16)

第四節 Federation Search

“Federation”的定義為將許多的註冊單元聚集在一起，並不是指兩兩之間完全地結合在一起，而是指說每個分散的註冊單元是藉著鬆散式耦合(loosely- coupled)結合在一起的。

圖 3.5 Federation 之系統示意圖

3.4.1 Federation 簡介

在ㄧ個 Federation 的系統中，每ㄧ個註冊單元在系統中都擁有相同的角色，因為ㄧ個 Federation 的系統的系統是屬於點對點(peer-to-peer)的模組，

因此，任何一個註冊單元都可以產生、加入、脫離、刪除某ㄧ個 Federation 的系統，同時，ㄧ個註冊單元也可以屬於很多不同的 Federation 系統。

當使用者在 federation 系統中的某個註冊單元，用關鍵字查詢時，這個關鍵字會送到這個 federation 系統中的所有註冊單元，之後所有的註冊單元會將結果回傳到原先發出查詢的註冊單元。所以，使用者就可以不必到每一個註冊單元，去下相同的關鍵字，可以增加效率。

Registry-2

Organization-B

Registry-

1

Organization-A

Organization-B

Individual Registries Registry Federation

(17)

FFP(Federation Policy Profile)，是指說儲存資訊的相關特性與註冊單元彼此之間關係的管理，FPP 應該在 Federation 的成員中流通分享。

FPP(Federation Policy Profile)的內容包含了下列幾點:

9 註冊單元的簡介:註冊單元的名稱、說明、版本、相關行業的資訊、註冊管理者…等。

9 資訊之間的連結。

9 Federation Query 的資訊。

9 事件通知的訊息。

9 回覆的訊息。

9 安全性的資訊。

依照 FPP(Federation Policy Profile)的規則，使用者可以利用兩種不同的方式分享 Federation Home 的資訊。

9 方法一:改變在註冊單元內的資料，並與聯盟的後設資料(Federation metadata)結合起來。

9 方法二:對於想要加入 Federation Home 的註冊單元，它們若可以呈現出 web page 並且自行輸入資料的話，如此它們就可以分享 Federation Home 的資訊了。

在生命週期中(Lifecycle)，一個有效率的管理所有活動的策略，是有需要的。而策略的內容則包含了，建立 Federation、成員註冊、模組化、更新、離開與刪除 Federation。以下表簡單說明其管理策略:

(18)

生命週期（Lifecycle）內容(Content) 建立(Creating) 原則上，任何具體呈現出 ebRS、ebRIM2.5 規格的註冊單元均

可建立 Federation。然而，建議希望是由國際組織或代表性的聯盟，為每個商業交易，來建立註冊單元；由官方國際單位來管理 Federation 與 Federation Home list。當許多地區的 Federation 系統建立起來時，此時就必須要由相關的組織來管理此 Federation List。

加入(Joining) 對於想要加入此 Federation 系統成員的單元來說，檢查技術元件(如:商業項目/商業型式、支援的功能、版本…)是有需要的。Federation Home 仔細地檢查與許可想要加入

Federation 的註冊單元。原則上，一個註冊單元可以加入很多不同的 Federation。然而，考慮 Federation 的管理方便性與實際狀況後，建議一個註冊單元只加入一個 Federation 系統。

離開(Leaving) 離開 Federation 是由 Federation Home 或是成員的要求來決定的。當 Federation 的成員要離開時，此成員必須詢問 Federation 的管理者，並且明白地提出離開的原因；之後 Federation Home 會檢視、許可。假使成員不管理當中的資料且幾乎不進行活動，此時 Federation Home 可以自行決定讓它們離開；然而此情況不易發生。

刪除(Deleting) 當 Federation 成員缺席、無執行商業交易及不需要

Federation 時，Federation Home 可以終止 Federation 系統。然而，當 Federation Home 要取得所有成員的同意，並且最起碼在一個星期前，要送訊息告知要終止 Federation，

以便成員可以做好準備。

表 3.1 Federation 之生命週期表

3.4.2 Federation Home 介紹 Federation Home:

一、管理註冊成員(Managing Registry Members)

9 負責管理 Federation 的成員名單與管理者名單，監控成員上線(on-line) 或下線(off-line)的狀況。

9 定期地監控與管理 Federation 成員的狀態、線上成員的數目…等等，以避免在 Federation 中，出現有問題的成員。

(19)

9 確認與核對相關的概況，以避免 Federation 成員無意義的增加。

9 鼓勵 Federation 成員去獲取最新的資訊。

二、規範資訊(Standard Information)

9 Federation Home 負責維護與管理所有成員均可使用的資訊。

9 檢查是否系統有保持在最新版本的狀態下，或是否現出現在商業型式的趨勢。

9 當使用者想要得到感興趣的事物，

9 管理內容中支援的新類型。

三、聯盟規範(Federation Policies)

9 定期地檢查支援管理 Federation Lifecycle 的功能是否正常。

9 在 Federation 上的後設資料(metadata)有所改變時，需傳送資料給成員，

以達到資料的一致性。

四、答覆管理(Replication Management) 9 定期地管理與確認答覆功能是否正常運作。

9 Federation Query 會替整個 Federation 系統帶來一定的工作負荷量。假使 Q&A 的答覆太多時，此時必須要確保 Federation 系統內的資源是一致的。

因此，可以增加 Q&A 資訊答覆可靠度與少量資料更新的策略是必要的；相對的，大量資訊的更新與 Q&A 答覆也需要新的策略來增加在 Federation Query 上的可靠度。

五、聯盟管理者(Federation Administrator)

9 Federation Home 的一般使用者、Federation Home 的管理者與 Federation administrators 都是 Federation 系統的使用者。

(20)

9 Federation Home 的一般使用者可以執行建立、模組化、刪除與 Q&A 等等…

的功能。

9 而 Federation Home 的管理者可以准許或拒絕一般使用者的問題，並且可以執行管理 Federation Home 的功能。

9 Federation administrator 執行在 Federation Lifecycle 上的多個功能；

同時，Federation Home 的管理者也是 Federation 的管理者。