程式設計者天堂

我們引用知識程序描述來明確描述建造入口的步驟如下：
1. 匯入ontology：建立或選擇ontology當作骨架schema的metadata
2. 標註：根據ontology去標註入口網站的內容。
3. 索引：事先為metadata建立索引。
4. 使用：metadata的索引已經準備好被應用程式使用。
5. 維護：重複第一個步驟如果有新的ontology被製造。
下面是詳細描述上述步驟

匯入ontology
在這個步驟需要準備ontology被當作schema使用，目的是為了用來描述入口網站的內容。在這篇文章中，我們決定去選擇現成的ontology來實現我們的目的，取代我們必須建立一個新的。Ontology 的來源主要是從DAML Ontology Library中取得的。既然我們現在的領域是圖書館，我們建立ontology 來描述出版人，討論區、時間、新聞和事件。出版的ontology是書、雜誌、期刊的子分類，人的ontology有作者和使用者兩個子分類。
匯入ontology 使用OntoEdit標註工具。

標註
標注的步驟是用metadata將入口網站作標註。我們使用OntoEdit當作標註的工具完成我們的metadata。完成前面的步驟之後，我們將ontology匯入OnroEdit中，OntoEdit會產生類別的階層。入口的內容需要被標記成(1)不同的文件格式像HTML和RDF(2)匯入SQL資料庫中的資料，(3)使用者的個人分析資料(profile)，和(4)在論壇中所討論的資料。第一種型態的文件包含新聞和事件。這種型態的每一份文件，不論是新聞或事件類別我們都建立資料項(instance)。在標註器在每一個屬性中填入數值，標註工具將在使用者介面上顯示一個新的資料項。完成這項工作之後，我們將這些資料項輸出存檔成RDF的檔案。書、期刊和雜誌的資料內容屬於第二種型態的資料類別。既然資訊被保存在資料表中因此我們需要將資料從資料表中抽出來，然後根據schema將他們存成RDF的檔案(使用Java SAX APIs)。第三種類別的metadata描述個人的資訊，包含感興趣的主題、行程和資訊內容。一個個人資訊是當一個人訂購入口網站時被建立。使用者進入個人資訊透過表格的介面。在傳送出表格中的內容之後資訊將被存放在RDF檔案中，根據個人檔案描述紀錄的schema。最後一種型態的資料內容被建造的方式和第三種很相似。入口網站提供一個表格介面給使用者去發表他們的意見。在表格區域中的資料將被整理，透過討論區ontology的schema，將資料收集轉換存放在RDF檔案中使用forum schema。

索引
索引步驟的工作是剖析RDF檔案蒐集前一步中的資料然後存入關連性資料庫中。我們使用RDF剖析器，SiRPAC去轉換RDF檔案成為對應的三元組敘述。我們建立一個表去儲存這些轉換的結果。為每一個ontology我們建立一個表對應ontology的schema。每一個三元組被當作一筆資料存在表格中。

使用
在這個步驟中我們提供服務給使用者存取入口網站的資料。在這篇文章中，我們提供使用者概念式的搜尋、目錄服務、新聞的過濾和事件的公告發布，還有論壇服務。概念式的搜尋和目錄服務兩者都在ontology建立概念是層級。概念式搜尋的介面提供使用者明確的詢問，透過屬性和值的一對關係找到目標的類別。我們的搜尋引擎在RDF中尋找可以滿足條件的資料項並回傳結果給使用者。目錄服務的介面是列出類別的基礎，使用者可以選擇感興趣的類別，可以將它展開看到此類別中更細節的資料，並且列出相關的資料。入口網站提供個人化的代理服務如下：新聞的過濾、事件的公告、書籍的預約。新聞的過濾和事件的公告的服務讓使用者透過電子郵件或者是短訊的方式去選擇新聞和感興趣的新事件。最後，討論區的服務提供一個地方讓使用者交換特殊主題的意見。它是一個使用者的圖形化介面讓使用者可以在每一個領域中輸入他們的資料，而不需要知道背後的類別架構層次。最後的結果資料從使用介面輸出後被收集存入RDF中。然後我們使用先前描述過的概念式搜尋和目錄服務去幫助使用者存取內容。論壇服務透過使用者的個人描述檔(user’s profile)提供個人化的服務，如文章主題的過濾。
這樣的雛型被建立之後，我們需要蒐集使用者使用後的建議，提供更多的函式以增加入口網站更多的功能提。當我們修正和提升應用程式的服務時，ontology可能需要被修正或者要被重新創造一個，並且回到第一個步驟重新開始。