Tiểu luận 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