Đề tài Tích hợp dữ liệu trong semantic web

ÑAÏI HOÏC HUEÁ TRÖÔØNG ÑAÏI HOÏC KHOA HOÏC TIEÅU LUAÄN MOÂN HOÏC SEMANTIC WEB Đề tài: TÍCH HÔÏP DÖÕ LIEÄU TRONG SEMANTIC WEB Giaùo vieân höôùng daãn : TS. Hoaøng Höõu Haïnh Hoïc vieân thöïc hieän: Nhoùm 7 Nguyeãn Trí Nhaân Traàn Thaùi Sôn Traàn Kieân Nguyeãn Thò Truùc Quyønh Lôùp Cao hoïc Khoa hoïc maùy tính – Khoaù 2008 - 2010 Hueá, thaùng 12/2009 MỤC LỤC MỞ ĐẦU Mục tiêu ban đầu của Semantic Web là để hỗ trợ người dùng tìm kiếm thông tin trên mạng một cách nhanh chóng, chuẩn xác và thông minh hơn so với các công cụ tìm kiếm truyền thống. Kể từ đó đến nay, các kỹ thuật liên quan đến Semantic Web không ngừng được hoàn thiện, các ứng dụng liên quan đến Semantic Web cũng được mở rộng như: Phát triển các chuẩn công nghệ chung để biểu diễn thông tin và cho phép máy tính có thể hiểu được một số thông tin trên Web, hỗ trợ tìm kiếm  thông minh hơn, hỗ trợ việc khám phá, tách chiết thông tin, tích hợp dữ liệu và tự động hóa một số công việc thay cho con người. Trong giới hạn của bài tiểu luận, nhóm chúng tôi tìm hiểu các phương pháp tích hợp các nguồn dữ liệu XML trong Semantic Web bằng hệ thống AutoMed. Nội dung của tiểu luận gồm có: Tổng quan về AutoMed Lược đồ chuyển đổi các nguồn dữ liệu XML Chuyển đổi và tích hợp các nguồn dữ liệu XML trong AutoMed Chúng tôi xin chân thành cảm ơn Thầy giáo Hoàng Hữu Hạnh đã tận tình giảng dạy. Mặc dù chúng tôi đã cố gắng nghiên cứu và tổng hợp các nguồn tài liệu để hoàn thành tiểu luận nhưng do thời gian có hạn nên chắc chắn sẽ có một số sai sót, chúng tôi mong nhận được những ý kiến đóng góp của Thầy giáo Hoàng Hữu Hạnh và các anh chị học viên lớp cao học Khoa học Máy tính khóa 2008. Nhóm 7-KHMT08 Nguyễn Trí Nhân Trần Kiên Trần Thái Sơn Nguyễn Thị Trúc Quỳnh B. NỘI DUNG 1. Tổng quan về AutoMed AutoMed là một hệ thống tích hợp dữ liệu không đồng nhất hỗ trợ chuyển đổi lược đồ để tích hợp dữ liệu. Hình 1: mô tả cách tiếp cận AutoMed để tích hợp dữ liệu XML. Mỗi nguồn dữ liệu được mô tả bởi một lược đồ nguồn dữ liệu, kí hiệu Si, nó được chuyển đổi thành 1 hợp lược đồ thích hợp USi bởi một tập các bước chuyển đổi nguyên thuỷ, do đó sẽ tạo ra một lộ trình chuyển đổi giữa lược đồ nguồn dữ liệu với hợp lược đồ tương ứng. Tất cả các hợp lược đồ đều đúng cú pháp và được xác định bởi các id chuyển đổi giữa mỗi cặp USi và USi+1 của các hợp lược đồ. ID là một loại đặc biệt của bước chuyển đổi nguyên thuỷ, nó nối hai cấu trúc đúng cú pháp trong hai lược đồ khác nhau biểu diễn tương đương về mặt ngữ nghĩa. Lộ trình chuyển đổi bao gồm các ID có thể được tự động sinh ra. Sau đó một lược đồ bất kỳ của các hợp lược đồ được chỉ định là một lược đồ tổng thể hoặc được lựa chọn để chuyển đổi thành một lược đồ mới có khả năng trở thành lược đồ tổng thể. Để hoàn thành việc chuyển đổi một lược đồ nguồn dữ liệu thành hợp lược đồ phải áp dụng các bước chuyển đổi nguyên thuỷ như: Add, Delete hoặc Rename cấu trúc lược đồ. Mỗi thao tác Add, Delete được đi kèm bởi một truy vấn chỉ rõ việc mở rộng của một cấu trúc mới được thêm vào hoặc bị xoá trong giới hạn của các cấu trúc lược đồ khác. Truy vấn này được biểu diễn bởi ngôn ngữ IQL(Intermediate Query Language) của AutoMed. Truy vấn được hỗ trợ bởi một thao tác chuyển đổi nguyên thuỷ nhằm cung cấp thông tin cần thiết để tự động nghịch đảo chuyển đổi nguyên thuỷ. Điều này có nghĩa: AutoMed là một hệ thống tích hợp dữ liệu both-as-view(BAV) [15], trong đó thao tác Add/Extend trong lược đồ chuyển đổi tương ứng với các luật Global-As-View (GAV), ngược lại thao tác Delete/Contract tương ứng với luật Local-As-View(LAV). Nó có thể trích lọc một định nghĩa của lược đồ tổng thể như một view qua các lược đồ nguồn dữ liệu và cũng có thể trích lọc các định nghĩa của các lược đồ nguồn dữ liệu như các view qua lược đồ tổng thể. Trong Hình 1 mỗi USi có thể chứa thông tin từ các nguồn Si tương ứng. các cấu trúc này không được chèn vào USi thông qua thao tác Add, ngược lại thông qua thao tác Extend. Cần hai truy vấn để xác định ranh giới mức thấp hơn và cao hơn khi mở rộng cấu trúc mới. Ranh giới thấp hơn có thể là Void và ranh giới cao hơn có thể là Any, chúng xác định tách biệt mà không biết thông tin về ranh giới thấp hơn và cao hơn của sự mở rộng một cấu trúc mới. Có thể có những thông tin có trong một lược đồ nguồn dữ liệu Si nhưng không có trong USi tương ứng, và thông tin này bị gỡ bỏ bởi thao tác Contract mà không phải bởi thao tác Delete. Giống như Extend, Contract cần hai truy vấn để xác định ranh giới mức thấp hơn và cao hơn khi mở rộng cấu trúc bị xoá. Khi thiết lập tích hợp dữ liệu XML, mỗi nguồn dữ liệu XML được mô tả bởi một lược đồ XML DataSource kí hiệu Si, chuyển đổi thành một lược đồ trung gian Ii, bởi các thao tác chuyển đổi nguyên thuỷ như Insert, Remove, Rename các cấu trúc lược đồ. Sau đó hợp các lược đồ sinh ra tự động và chúng mở rộng mỗi Ii với các cấu trúc còn của các lược đồ trung gian. Sau đó các lộ trình chuyển đổi giữa USi và USi+1 của các hợp lược đồ cũng được tự động sinh ra. Framework tích hợp XML hỗ trợ hai phương pháp tích hợp lược đồ Top-Down và Bottom-Up. Với phương pháp Top-Down, lược đồ tổng thể được định nghĩa trước và cấu trúc lược đồ dữ liệu được cấu trúc lại để nối với cấu trúc của nó. Với phương pháp Bottom-Up lược đồ tổng thể không được định nghĩa trước nhưng được tự động sinh ra. Hình 1: Tích hợp XML trong AutoMed 2. Lược đồ biểu diễn các nguồn dữ liệu XML Khi mã hoá dữ liệu trong XML, có hai cách thức bắt buộc các kiểu và cấu trúc dự định qua các file XML: lược đồ XML và DTD. Tuy nhiên, những kĩ thuật này cung cấp một cú pháp phức tạp của một file, chúng mô tả một cấu trúc có thể có của một file, không phải một cấu trúc thực tế. Cấu trúc của một file XML rất quan trọng trong tích hợp dữ liệu, tích hợp lược đồ và trong tối ưu hoá truy vấn. Có thể nói rằng một file XML có thể không có lược đồ XML hoặc DTD tham chiếu. Vì những lý do này, giới thiệu lược đồ XML DataSource (XML DataSource Schema), tóm tắt cấu trúc của một file XML, lược bỏ bớt thông tin chẳng hạn thông tin về các kiểu dữ liệu. Khái niệm lược đồ XML DataSource tương tự với DataGuide. Tuy nhiên, lược đồ XML DataSource là các cây XML trong khi đó DataGuide là các đồ thị OEM. Để có được lược đồ XML DataSource, đầu tiên sao chép file XML vào bộ nhớ, trong miền biểu diễn của nó. Thuật toán xây dựng lược đồ XML sau khi sao chép file XML. Gọi R là gốc. Nếu R có các nút con, gọi danh sách các nút con là L. a. Xét nút con đầu tiên trong L là nút N. For N’ Î {L\N} có cùng đích với N sao chép các thuộc tính của N’ mà không xuất hiện trong N qua nút N. sao chép và gắn danh sách chứa các nút con của N’ vào danh sách chứa các nút con của N. Xoá nút N’ và cây con của nó. b. Xét nút con tiếp theo của L và thực hiện như (a). Xét mỗi nút trong danh sách chứa nút con mới của R. AutoMed có một mô hình dữ liệu phổ biến thường dùng là Hypergraph Data Model (HDM). Đây là mô hình dữ liệu mức thấp có thể biểu diễn các ngôn ngữ mô hình hoá mức cao như mô hình quan hệ ER, mô hình hướng đối tượng và mô hình XML. Lược đồ HDM bao gồm các nút, các cạnh và các ràng buộc. Lựa chọn một mô hình dữ liệu phổ biến mức thấp cho hệ thống AutoMed là có chủ ý trước, cũng có thể biểu diễn các ngôn ngữ mô hình hoá mức cao tốt hơn mà không bị nối ghép sai và tối nghĩa. Bảng 1 mô tả cách biểu diễn cấu trúc lược đồ XML DataSource trong HDM. Lược đồ này gồm 4 cấu trúc như sau: Element: Một element e có thể chính nó tồn tại và là cấu trúc một nút. Nó được biểu diễn bởi lược đồ Attribute: Một thuộc tính a của e là một cấu trúc liên kết nút và được biểu diễn bởi lược đồ . Trong HDM chúng được biểu diễn bởi một nút mô tả thuộc tính và một cạnh nối nút này với nút mô tả e, có ràng buộc một thực thể của e có nhiều nhất một thực thể kết hợp với nó và thực thể này có thể kết hợp với một hoặc nhiều thực thể với e. NestList: Mối quan hệ cha-con giữa 2 element ep và ec là một cấu trúc liên kết với lược đồ , trong đó i là thứ tự của ec trong danh sách các nút con của ep. Trong HDM, mối quan hệ này được biểu diễn một cạnh nối ep và ec và một ràng buộc mỗi thực thể của ep được kết hợp với 0 hoặc nhiều thực thể của ec và mỗi thực thể của ec chỉ kết hợp với một thực thể của ep. PCDATA: văn bản trong XML được biểu diễn bới cấu trúc PCDATA. Đây là một cấu trúc nút với lược đồ . Trong một lược đồ bất kì, chỉ có một cấu trúc PCDATA biểu tất cả các thực thể của PCDATA trong một tài liệu XML. Để liên kết cấu trúc PCDATA với một Element, xem nó như một Element và sử dụng cấu trúc NestList. Ở đây IQL là ngôn ngữ truy vấn dựa trên danh sách đã có, do đó chỉ sử dụng một cấu trúc NestList. Nút con thứ n của nút cha có thể được xác định bởi một truy vấn định rõ NestList tương ứng, và nút được yêu cầu sẽ là mục thứ n trong danh sách kết quả IQL. Một vấn đề trong lược đồ XML DataSource là các Element XML trùng tên tại các vị trí khác nhau. Vấn đề này được mở rộng khi gặp nhiều file. Trong lược đồ XML DataSource, sử dụng đinh danh: trong đó SchemaName là tên lược đồ được định nghĩa trong AutoMed, và Count là một biến đếm được tăng lên mỗi lần gặp elementName cùng tên khi duyệt sâu đầu tiên(Depth-first) lược đồ. Đối với tài liệu XML, wrapper XML tạo ra một định danh duy nhất có dạng trong đó instance là một biến đếm được tăng lên mỗi lần gặp instance mới của element lược đồ tương ứng trong tài liệu. Bảng 1 Biểu diễn lược đồ nguồn dữ liệu XML theo HDM Higher Level Construct Equivalent HDM Representation Construct: Element Class nodal Scheme Node: Construct: Attribute Class: nodal-linking, constraint Schema: Node: Edge Links Cons makeCard Construct NestList Class linking, constraint Scheme Node: Edge Links Cons makeCard Construct: PCDATA Class nodal Scheme Node Ví dụ: Minh họa lược đồ XML DataSource Schemas, xét tài liệu XML sau: Dr. G. Grigoriadis 123 Prof. A. Karakassis 111 Dr. A. Papas 321 Lược đồ XMLDSS trích lọc từ tài liệu này là S1 trong hình 2 Hình 2: Các lược đồ XMLDSS S1 và S2, lược đồ RDFS R1 và các lược đồ XMLDSS tương đương IS1 và IS2 3. Chuyển đổi và tích hợp các nguồn dữ liệu XML trong AutoMed 3.1 Thuật toán chuyển đổi lược đồ Thuật toán chuyển đổi lược đồ có thể được áp dụng theo hai cách: top-down, trong đó lược đồ tổng thể được định nghĩa trước và các lược đồ nguồn dữ liệu được chuyển đổi để đối sánh với nó, không quan tâm đến việc mất thông tin; còn bottom-up thì lược đồ tổng thể không được định nghĩa trước và thông tin của tất cả các nguồn dữ liệu là được duy trì. Cả hai phương pháp tạo các lộ trình chuyển đổi sinh ra các lược đồ trung gian với cấu trúc đúng. Sau đó các lược đồ này được tự động chuyển đổi thành các hợp lược đồ USi trong hình 1, bao gồm các lộ trình id giữa chúng. Sau đó lộ trình chuyển đổi từ một lược đồ USi đến lược đồ tổng thể GS có thể được tạo ra theo một trong hai cách: tự động sinh ra sử dụng các ngữ nghĩa ‘append’, hoặc bán tự động, trong đó các truy vấn hỗ trợ chuyển đổi chỉ rõ sự tích hợp cần được hỗ trợ bởi người dùng. Theo cách thứ nhất, việc mở rộng các cấu trúc của các lược đồ tổng thể được tạo ra bằng cách gắn mở rộng các cấu trúc của các cấu trúc tương ứng: US1, US2,…,USn theo thứ tự. Vì vậy nếu nguồn dữ liệu XML được tích hợp theo một thứ tự khác, mở rộng mỗi cấu trúc của lược đồ tổng thể nên chứa các instance tương tự, nhưng thứ tự của nó là khác nhau. Phương pháp Top-down: Xét một thiết lập, trong đó một lược đồ tổng thể GS được cho trước và các lược đồ nguồn dữ liệu phải phù hợp với nó, không cần thiết phải duy trì lượng thông tin của chúng. Thuật toán làm việc theo hai phase, trong growing phase, GS được duyệt và mỗi cấu trúc không hiển thị trong lược đồ nguồn dữ liệu Si được chèn vào. Trong shringking phase mỗi lược đồ Si được duyệt và và bất kỳ một cấu trúc không có trong lược đồ tổng thể thì bị gỡ bỏ. Thuật toán chuyển đổi một XML DataSource Schema S1 là có cùng cấu trúc như một XML DataSource Schema S2 được mô tả dưới đây. Thuật toán này xét một element trong S1 tương đương với một element trong S2 nếu chúng có cùng tên. Thuật toán giả sử tên của các element trong S1 và S2 là duy nhất. Growing phase: xét mỗi element E trong S2 theo thứ tự duyệt sâu: Nếu E không tồn tại trong S1: a. Tìm trong S1 một thuộc tính a có cùng tên với tên với E trong S2 i) Nếu tìm thấy thì Add E vào S1 với mở rộng của thuộc tính a và Add một cạnh từ một element trong S1 tương đương với owner(a,S2) đến E. ii) Ngược lại thì Extend E. Sau đó tìm element tương đương của quan hệ parent(E,S1) trong S2 và Add một cạnh từ nó đến E với thao tác Extend iii) Cả hai trường hợp, chèn các thuộc tính của E trong S2 vào element E mới được chèn trong S1 với thao tác Add hoặc Extend, phụ thuộc vào việc có thể mô tả sự mở rộng của một thuộc tính bằng cách sử dụng cấu trúc còn lại của S1. Lưu ý rằng một hoặc nhiều hơn các phép chèn như thế có thể xảy ra tình trạng chuyển một element của S1 thành một thuộc tính. b. Nếu E được liên kết đến một cấu trúc PCDATA trong S2: i) Nếu cấu trúc PCDATA không có trong S1 thì chèn nó với thao tác Extend, sau đó chèn thêm một cạnh từ E đến cấu trúc PCDATA với thao tác Extend. ii) Ngược lại, Add một cạnh từ E đến cấu trúc PCDATA. Nếu E tồn tại trong S1 và parent(E,S2)= parent(E,S1) thì: Chèn các thuộc tính của E trong S2 nhưng không xuất hiện trong E thuộc S1, tương tự như 1(a)iii. Nếu E được liên kết đến cấu trúc PCDATA trong S2, tương tự như 1.b. Nếu E tồn tại trong S1 và parent(E,S2) ¹ parent(E,S1) thì: Chèn một cạnh từ Ep đến E, trong đó Ep là element tương đương của parent(E,S2) trong S1. Việc chèn này có thể hoặc là một thao tác Add hoặc thao tác Extend, phụ thuộc vào đường đi từ Ep đến E. Thuật toán tìm đường đi ngắn nhất từ Ep đến E và nếu nó chỉ bao gồm các cạnh từ parent đến child thì thao tác chuyển đổi là Add ngược lại là Extend. Chèn các thuộc tính của E trong S2 không xuất hiện trong E thuộc S1, tương tự 1.a)iii Nếu E được liên kết đến một cấu trúc PCDATA, tương tự 1.b. Shrinking phase: Duyệt qua S1 và gỡ bỏ những cấu trúc không xuất hiện trong S2 Renaming phase: Duyệt qua S1 và đổi tên các nhãn của cạnh nếu cần thiết để tạo ra một thứ tự liên tục của các identifier. Trong bước 3a, thuật toán quyết định cho dù đưa ra thao tác Add hay Extend, phụ thuộc vào kiểu các cạnh mà đường đi từ Ep đến E chứa nó. Để lý giải điều này, giả sử rằng đường đi bao gồm tại một điểm nào đó một cạnh (B,A), trong đó trong S1, element A là parent của B. Có trường hợp trong S1, có một vài instance của A mà chúng không có các instance của B là children. Kết quả là, khi di chuyển dữ liệu từ S1 đến S2, một vài dữ liệu sẽ bị mất, các instance đó của A không có bất kì một children nào của B. Để khắc phục điều này, thao tác Extend được đưa ra với truy vấn có đường biên thấp hơn và truy vấn có đường biên cao hơn. Truy vấn đầu tiên lấy lại dữ liệu thực sự từ S1 nhưng có thể mất vài dữ liệu do vấn đề mô tả dữ liệu. Truy vấn thứ hai lấy lại tất cả dữ liệu mà truy vấn thứ nhất đã lấy lại, nhưng cũng sinh ra các instance mới của B (có ID duy nhất) để duy trì những instance của A mà truy vấn thứ nhất không làm được. Có trường hợp không như mong đợi nên người dùng cần lựa chọn thuật toán có hiệu quả để chỉ sử dụng Any như một truy vấn có đường biên cao hơn. Một ví dụ áp dụng thuật toán được minh hoạ trong Hình 3. Lộ trình chuyển đổi tương ứng được trình bày trong Bảng 2 và phân thành 3 đoạn. Đoạn 1 minh hoạ growing phase, trong đó các cấu trúc của lược đồ S2 được thêm vào S1. Đoạn 2 minh hoạ shrinking phase, trong đó các cấu trúc của S1 không xuất hiện trong S2 sẽ bị gỡ bỏ. Đoạn 3 minh hoạ Renaming phase. Hàm generateElemUID tạo ra các instance element từ các instance thuộc tính và có nghĩa khi một thuộc tính được chuyển đổi thành một element và ngược lại (xem g7, g9 và s2, s4 trong bảng 2). Việc kết hợp các phép toán chèn và gỡ bỏ của AutoMed cho phép chuyển đổi phức tạp hơn. Ví dụ, trong bước 1(a)i, một thuộc tính chuyển đổi thành một element (ví dụ xem g7 trong bảng 2); trong bước 1(a)iii, các element có thể được chuyển đổi thành các thuộc tính (ví dụ g2 trong bảng 2). Cuối cùng, trong bước 3(a) mô phỏng phép toán di chuyển (ví dụ g3). Thuật toán được trình bày ở trên giả sử các element trong S1 và S2 có tên duy nhất. Tổng quát chúng ta có thể gặp các trường hợp sau: Một element trong S1 có nhiều elementname nhưng trong S2 có một elementname Một element trong S2 có nhiều elementname nhưng trong S1 có một elementname Một element trong S1 có nhiều elementname và một element trong S2 có nhiều elenmentname. Đối với trường hợp a: Thuật toán cần đưa ra một truy vấn để tạo ra sự mở rộng của element chỉ có một elementname trong S2 bằng cách nối các mở rộng của 3 element từ S1. Trường hợp b: Thuật toán cần có sự chọn lựa các element từ S1 di chuyển mở rộng của một element đơn trong S2 sang. Đối với trường hợp này, phải áp dụng chiến lược heuristic sẽ thuận lợi: (i) các lộ trình với một vài bước Extend và (ii) với ngắn nhất của các lộ trình. Trường hợp c: ên áp dụng kết hợp các giải pháp cả trường hợp a và b. Hình 3: Ví dụ chuyển đổi lược đồ Bảng 1: Quá trình chuyển đổi của Hình 3 Growing phase:  Shrinking phase: Renaming phase Phương pháp Bottom-up: Trong phương pháp này, lược đồ tổng thể GS không được định nghĩa trước nhưng được sinh ra tự động từ các lược đồ nguồn dữ liệu, không mất thông tin. Lược đồ nguồn dữ liệu Si đầu tiên được chuyển thành các lược đồ trung gian USi . Sau đó các hợp lược đồ USi được sinh ra theo các id. Bắt đầu thực hiện lược đồ trung gian của lược đồ nguồn dữ liệu đầu tiên là chính nó, tức là: S1 = US11. Sau đó thuật toán thực hiện trên IS11 và S2 (hình 3).Thuật toán thêm vào IS11các cấu trúc trong S2 nhưng không có trong IS11. Thuật toán cũng cấu trúc lại S2 để nối các cấu trúc IS11, thêm vào S2 các cấu trúc có trong IS11 mà nó không có. Kết quả IS11 được chuyển đổi thành IS21 và S2 chuyển thành IS12. Quá trình thực hiện tương tự cho IS12 và S3, tạo ra IS22 và IS13 . tiếp tục cho IS21 và IS22, kết quả chỉ tạo ra IS31vì lúc này IS21 không chứa bất kỳ một cấu trúc nào mà IS22 cũng không có. Các lược đồ trung gian còn lại cũng được sinh ra tương tự: để tạo ra lược đồ ISi , thuật toán chuyển đổi lược đồ thực hiện trên IS1i-1 và Si, kết quả tạo ra IS2i-1 và IS1i; tất cả các lược đồ trung gian khác ngoại trừ IS2i-1 và IS1i được mở rộng bằng cách thêm các cấu trúc của Si mà chúng không có. Cuối cùng tự động sinh ra các hợp lược đồ USi thông qua các id và lược đồ tổng thể (bằng cách thêm các ngữ nghĩa). Hình 4: Tích hợp các lược đồ XML DataSource Schema 3.2 Phép tương đương lược đồ Các cách tiếp cận khác để chuyển đổi hay tích hợp dữ liệu XML không sử dụng RDF/S hoặc OWL có trong [16,18-20,23]. Trong [24, 25] cũng thảo luận về sự chuyển đổi và tích hợp các nguồn dữ liệu XML. Tuy nhiên, các bài báo đã không thể sử dụng các phép tương giữa các nguồn dữ liệu và các ontologies. Cách tiếp cận ở đây có thể sử dụng thông tin để xác định một element/attribute trong một nguồn dữ liệu tương đương với một lớp cha (supperclass) hoặc một lớp con (subclass) của một element/attribute trong một nguồn dữ liệu khác. Thông tin này được tạo ra từ các phép tương đương giữa các nguồn dữ liệu và các ontologies. Điều này cho phép các mối quan hệ có ngữ nghĩa hơn được suy ra giữa các nguồn dữ liệu và do đó có nhiều thông tin hơn được giữ lại từ một nguồn dữ liệu khi nó được chuyển thành một định dạng đích. Một phép tương đương xác định một phần tử (Element) hay một thuộc tính (Attribute) của một lược đồ XML DataSource Schema bởi một truy vấn path query IQL qua một lược đồ RDFS. Cụ thể, một phần tử (Element) e có thể ánh xạ đến lớp c hoặc đến đường dẫn kết thúc với một thuộc tính giá trị lớp có dạng: >, hoặc kết thúc đường dẫn với một thuộc tính giá trị literal có dạng: >; hơn nữa, các phép tương đương cho rằng các thực thể của một lớp thường bị ràng buộc bởi một số thành viên trong lớp con nào đó. Một Atrribute có thể ánh xạ đến một thuộc tính giá trị literal hoặc đến đường dẫn kết thúc với thuộc tính giá trị literal. Các phép tương đương ở đây tương tự với các phép tương đương path-path trong [1], với ý nghĩa là một lộ trình từ gốc của một lược đồ XML DataSource Schema đến một nút tương ứng với một lộ trình trong lược đồ RDFS. Ví dụ: Bảng 2 và 3 chỉ ra các phép tương đương giữa các lược đồ XMLDSS S1 và S2 và lược đồ RDFS R1 (Hình 2). Trong Bảng 2 phép tương đương thứ nhất ánh xạ phần tử > đến lớp >. Phép tương đương thứ hai trình bày mở rộng phần tử > tương đương với các thực thể của lớp School được suy ra từ hợp các thuộc tính > và > trên cấu trúc lớp phổ biến, College. Trong phép tương đương thứ 4, phần tử > tương ứng với các thực thể của lớp Staff được suy ra từ biểu thức đường dẫn được định rõ và đó cũng là thành viên của AcademicStaff. Trong phép tương đương thứ 5, hàm generateElemUID của IQL tạo ra nhiều thực thể cho phần tử > như là đã được định rõ bởi đối số thứ hai của nó, vv. Số thực thể của thuộc tính > trong biểu thức đường dẫn được chỉ định như là đối số cho hàm count. Các phép tương đương còn lại trong bảng 2 và 3 tương tự nhau. S1 R1 > > > [s | {c,u} ← >; {s,c} ← >] > [ s,l | {c,u} ← >; {s,c} ← >; {s,l} ← >])] > [s2 | {c,u} ← >; {s1,c} ← >; {s2,s1} ← >; member s2 >] > [o | o ← generateElemUID ’name’ (count[l | {c,u} ← >; {s1,c} ← >; {s2, s1} ← >; member s2 >; {s2, l} ← >])] > [o | o ← generateElemUID ‘office’ (count [l | {c,u } ← >; {s1,c} ← >; {s2,s1} ← >; member s2 >; {s2,l} ← >])] Bảng 2: Các phép tương đương giữa lược đồ XML DataSource S1 và R1 S2 R1 > [{s2, l } | {c, u} ← >; {s1, c} ← >; {s2, s1} ← >; {s2 ,l } ← >] > [s2 | {c, u} ← >; {s1, c} ← >; {s2, s1} ← >] > [o | o ← generateElemUID ‘office’ (count [{s2, l} | {c, u} ← >; {s1, c} ← >; {s2, s1} ← >; {s2, l} ← >])] > [{c, l} | {c, u} ← >; {c, l} ← >] > [c | {c, u} ← >] Bảng3: Các phép tương đương giữa lược đồ XMLDSS S2 và R1 Phép tương đương của lược đồ XML DataSoure Schema S1 và S2 tương đương với lược đồ XMLDSS IS1 với IS2, chúng biểu diễn các khái niệm giống nhau cùng một cách. Phép tương đương này đạt được nhờ đổi tên các cấu trúc của S1 và S2 bằng cách sử dụng các tập phép tương đương từ các lược đồ đến một ontology phổ biến. Với phép tương đương i trong tập các phép tương đương giữa một lược đồ XML DataSource Schema S và một ontology R , thao tác Rename trong AutoMed được tạo ra như sau: 1. Nếu i quan hệ với phần tử e: (a) Nếu e ánh xạ trực tiếp đến một lớp c thì đổi tên e thành c. Nếu các thực thể của c bị ràng buộc bởi thành viên trong một lớp con (subclass) csub của c thì đổi tên e thành csub. (b) Ngược lại, nếu e ánh xạ đến một đường dẫn trong R kết thúc với một thuộc tính giá trị lớp thì đổi tên e thành s, trong đó s là phép ghép các nhãn của lớp và các cấu trúc thuộc tính của đường dẫn, ngăn cách bởi dấu chấm ‘.’. Nếu các thực thể của một lớp c trong đường dẫn này bị ràng buộc bởi thành viên trong một lớp con (subclass) thì nhãn của lớp con được sử dụng thay thế cho s. c) Ngược lại, nếu e ánh xạ đến một đường dẫn trong R kết thúc với thuộc tính giá trị literal > thì đổi tên e như bước 1b nhưng không thêm nhãn Literal cho s. 2. Nếu i quan hệ với thuộc tính a thì a phải ánh xạ đến một đường dẫn trong R kết thúc với thuộc tính giá trị literal >, và nó đổi tên phần tử e như trong bước 1c. Chú ý không phải tất cả các cấu trúc của S1 và S2 cần được ánh xạ bởi các phép tương đương đến ontology. Những cấu trúc như vậy không bị ảnh hưởng và được xem là do pha cấu trúc lại lược đồ giai đoạn tiếp theo . Hình 2 cho thấy lược đồ IS1 và IS2 được tạo ra áp dụng đổi tên thành S1 và S2 phát sinh từ các tập phép tương đương trong bảng 2 và 3. 3.3. Tích hợp lược đồ Xét sự tích hợp của một tập các lược đồ XML DataSource Schema S1 ,..., Sn tất cả đều phù hợp với một ontology R vào một lược đồ XML DataSource tổng thể. Thuật toán đổi tên trong phần 2.2 đầu tiên được sử dụng để tạo ra các lược đồ XML DataSource Schema trung gian IS1 ,..., ISn. Lược đồ tổng thể ban đầu GS1 là IS1. Sau đó IS2 tích hợp với GS1 để tạo ra GS2. Sự tích hợp của ISi với GSi-1 để tạo ra GSi thực hiện tiếp tục cho đến khi i = n. Quá trình tích hợp này gồm: đầu tiên mở rộng GSi-1 với các cấu trúc từ ISi mà nó không có (lặp lại thông qua growing and a shrinking phase) và sau đó sử dụng thuật tóan trong phần 2.1 cấu trúc lại cho ISi với lược đồ kết quả GSi. 3.4. Truy vấn các file XML Cơ chế truy vấn và kiến trúc wrapper của AutoMed được thể hiện trong hình 4. Trong đó, Wrapper XML có thể được sử dụng trong ba cách thiết lập khác nhau: (i) Khi một lược đồ nguồn XMLDSS S1 đã được chuyển đổi thành một lược đồ XMLDSS đích S2, lộ trình kết quả S1 → S2 có thể được dùng để dịch một truy vấn IQL được biểu diễn trên S2 thành một câu truy vấn IQL trên S1, và wrapper XML của nguồn dữ liệu XML tương ứng với S1 có thể được sử dụng để lấy dữ liệu cần thiết cho trả lời câu truy vấn. ii) Khi tích hợp đa lược đồ nguồn dữ liệu với các lược đồ S1,. . . , Sn theo lược đồ GS tổng thể ảo, bộ xử lý câu truy vấn của AutoMed có thể xử lý một câu truy vấn IQL được biểu diễn trên GS kết hợp với các wrapper XML cho các nguồn dữ liệu tương đương với Si. (iii) Khi thiết lập chuyển đổi dữ liệu hay thiết lập tích hợp dữ liệu cụ thể, trong đó các XML wrapper của các nguồn dữ liệu (s) lấy dữ liệu và XML wrapper của lược đồ đích cụ thể hoá dữ liệu đưa vào định dạng lược đồ đích. Hai lớp AutoMedWrapperFactory và AutoMedWrapper là lớp trừu tượng thực thi một vài phương thức trừu tượng, trong khi đó các lớp XMLWrapperFactory và XMLWrapper sẽ thực thi các phương thức trừu tượng còn lại. các Factory liên quan đến các khía cạnh mô hình cụ thể chẳng hạn: các khoá chính trong cơ sở dữ liệu quan hệ. Một lớp XML-factory cụ thể chứa một bộ chuyển đổi. Khi bộ chuyển đổi ở trạng thái mở thì việc phân tích ngữ pháp file XML có đối tượng XMLWrapper gắn vào sẽ được thực hiện nhờ lược đồ DTD/XML. Số lượng các bộ chuyển đổi ví dụ một bộ chuyển đổi xoá đi các kí tự trắng sẽ được thêm vào trong tương lai. Hình 54 mô tả kiến trúc có thể được mở rộng wrapper cho các mô hình nguồn dữ liệu. Sau khi tạo các lộ trình chuyển đổi theo phương pháp tích hợp top-down hoặc bottom-up, các truy vấn được đưa lên lược đồ tổng thể có thể được tính toán. Một truy vấn được đưa lên Query engine được xử lý đầu tiên bởi Query processor, nó chịu trách nhiệm diễn đạt lại để tạo thành một truy vấn có thể được tính toán trên các nguồn dữ liệu. Điều này được hoàn thành dựa vào các lộ trình chuyển đổi ngược từ lược đồ tổng thể sang lược đồ nguồn dữ liệu. Khi gặp thao tác delete, contract hay rename, nó thay thế lược đồ bị gỡ bỏ hoặc đổi tên bởi một truy vấn hỗ trợ chuyển đổi. Kết quả, truy vấn nguyên thuỷ được chuyển thành một truy vấn có thể tính toán trên các nguồn dữ liệu. Bộ Fragment processor thay thế các truy vấn con IQL bởi các đối tượng XML wrapper. Sau đó bộ evaluator tính toán truy vấn, và yêu cầu đối tượng XML wrapper khi cần thiết. Lúc này, việc truy vấn các file XML được thực hiện bằng cách dịch các truy vấn IQL thành XPATH. Hình 5: Cơ chế truy vấn và kiến trúc Wrapper của AutoMed Ví dụ: giả sử rằng lược đồ S1 và S2 hình 2 được tích hợp thành lược đồ tổng thể GS trong Hình 6. Để lấy title và genre của một cuốn sách trong lược đồ tổng thể, truy vấn sau đây được đưa lên GS (để đơn giản bỏ thành phần element counter) Các phân mảnh của lộ trình chuyển đổi từ S1 và S2 đến GS phù hợp với truy vấn này là: Duyệt theo lộ trình GS® US1 và GS® US2, các truy vấn ở trên được viết lại như sau: Sau đó, duyệt theo lộ trình US1®S1 và US2®S2, ta có: Các instance của (Void, Any) có thể được loại bỏ, truy vấn cuối cùng có dạng: Hình 6: Lược đồ tổng thể GS 3.5. Xử lý nhiều Ontologies Làm thế nào có thể xử lý các lược đồ XMLDSS được liên kết đến các ontologies khác nau. Chúng có thể được kết nối trực tiếp thông qua lộ trình chuyển đổi AutoMed, hoặc thông qua một ontology khác (ví dụ như ontology ở mức trên) mà cả hai ontology được kết nối bởi một lộ trình AutoMed. Xét hai lược đồ XMLDSS cụ thể S1 và S2 được liên kết ngữ nghĩa bởi hai tập các phép tương đương C1 và C2 đến hai ontologies R1 và R2. Giả sử R1 trùng với R2 trong một lộ trình AutoMed giữa chúng. Đây có thể là một lộ trình trực tiếp R1 → R2. Ngoài ra, có thể có hai lộ trình R1 → RGeneric và R2 → RGeneric liên kết R1 và R2 đến nhiều ontology RGeneric tổng thể, từ đó có thể suy ra một lộ trình R1 → RGeneric → R2 (do tính ngược các lộ trình). Trong cả hai trường hợp, lộ trình R1 → R2 có thể được sử dụng để chuyển đổi các phép tương đương C1 được thể hiện trên. R1 đến một tập các phép tương đương C’1 thể hiện trên R2. Đây là cách sử dụng thuật toán chuyển đổi câu truy vấn được đề cập ở mục 3 trong đó thực hiện câu truy vấn sử dụng các bước xóa, rút gọn và đổi tên trong R1 → R2.  C. KẾT LUẬN - Thuật toán chuyển đổi lược đồ cho phép sử dụng các phương pháp kết nối nhiều loại lược đồ(sử dụng ontologies, semantic được cung cấp trong RDF, data-mining), có thể xem chúng là đầu vào của thuật toán tích hợp lược đồ. Đóng góp chính của công việc được trình bày ở đây là tích hợp tự động dữ liệu XML sử dụng một giải pháp XML sạch. - Thuật toán chuyển đổi cũng có thể được áp dụng trong việc cài đặt peer-to-peer. Giả sử rằng có một peer PT cần truy vấn đến dữ liệu XML được lưu trữ tại PS. Xem PS như là một peer có XML DataSource Schema cần được chuyển thành XML DataSource Schema PT. Sau khi áp dụng thuật toán này, PT truy vấn đến PS để lấy dữ liệu mà nó cần, vì cơ chế truy vấn của AutoMed xem lược đồ của PT như lược đồ tổng thể và lược đồ của PS là lược đồ địa phương. - Phép tương đương lược đồ: có thể sử dụng thông tin để xác định một element/attribute trong một nguồn dữ liệu tương đương với một lớp cha (supperclass) hoặc một lớp con (subclass) của một element/attribute trong một nguồn dữ liệu khác. Thông tin này được tạo ra từ các phép tương đương giữa các nguồn dữ liệu và các ontologies. Điều này cho phép các mối quan hệ có ngữ nghĩa hơn được suy ra giữa các nguồn dữ liệu và do đó có nhiều thông tin hơn được giữ lại từ một nguồn dữ liệu khi nó được chuyển thành một định dạng đích. D. TÀI LIỆU THAM KHẢO [1] Lucas Zamboulis and Alexandra Poulovassilis, “Information Sharing for Semantic Web-A Schema Transformation Approach”, 2006 [2] Lucas Zamboulis, “XML Data Integration By Graph Restructuring”, 2004 [3] L. Zamboulis and A. Poulovassilis, “Using AutoMed for XML data transformation and integration”. In Proc. DIWeb'04 (at CAiSE'04), Riga, Latvia, June 2004. [4] N. Rizopoulos, “BAV Transformations on Relational Schemas Based on Semantic Relationships between Attributes”, AutoMed Technical Report 22, August 2003.