Cách tiếp cận này làm cho việc sử dụng các dịch vụ ngữ nghĩa trong một ứng dụng cụ thể như xây dựng trang web tự động trở nên thân thiện với người sử dụng, đồng thời cơ sở dữ liệu để cập
Trang 1LUẬN VĂN TỐT NGHIỆP
ĐỀ TÀI
XÂY DỰNG MỘT KIẾN TRÚC CẬP NHẬP ĐỘNG NỘI DUNG TRANG WEB THEO HƯỚNG TIẾP CẬN SỬ DỤNG CÁC DỊCH VỤ WEB CÓ NGỮ NGHĨA THÔNG QUA CÁC MÔ
TẢ BẰNG NGÔN NGỮ TỰ NHIÊN
Hướng dẫn: TS Quản Thành Thơ Thực hiện: Nguyễn Bảo Toàn
Mã số HV: 00707189 Khóa học: 2007
– 2009 –
Trang 2LỜI CẢM ƠN
Tôi xin chân thành cảm ơn khoa Khoa học và Kỹ thuật máy tính, trường Đại học Bách Khoa TP Hồ Chí Minh đã hỗ trợ, tạo điều kiện thuận lợi cho tôi trong quá trình học tập cũng như quá trình thực hiện luận văn tốt nghiệp này
Nhân cơ hội này, tôi muốn bày tỏ lòng biết ơn sâu sắc đến TS Quản Thành Thơ, người đã tận tình hướng dẫn và có những đóng góp, gợi ý quý giá trong giai đoạn làm đề cương luận văn cũng như giai đoạn luận văn tốt nghiệp
Tôi cũng xin gởi lời cảm ơn chân thành đến PGS.TS Cao Hoàng Trụ, Ths Huỳnh Tấn Đạt đã có những sự hỗ trợ, giúp đỡ cũng như cung cấp những tài liệu trong suốt giai đoạn tôi thực hiện luận văn
Tôi xin trân trọng cảm ơn đến Phòng đào tạo Sau đại học, trường Đại học Bách Khoa TP.HCM đã hỗ trợ tôi rất nhiều trong thời gian học tập tại trường
Tôi cũng muốn bày tỏ lòng cảm ơn đến những người bạn và gia đình đã ủng hộ
và chia sẻ trong quá trình tôi học tập cũng như thực hiện luận văn
Trang 3TÓM TẮT LUẬN VĂN
Các nghiên cứu đi trước cho thấy các dịch vụ web có ngữ nghĩa có thể sử dụng
để quản lý và cập nhật thông tin tự động trên một hệ thống thông tin Tuy vậy để ứng dụng vào thực tế, bản thân dịch vụ web vẫn tạo ra rào cản kĩ thuật đối với người dùng thông thường Luận văn này sẽ khảo sát và phát triển một kiến trúc giúp người sử dụng có thể sử dụng miêu tả bằng ngôn ngữ tự nhiên để gọi các dịch vụ web có ngữ nghĩa Kiến trúc được xây dựng cần đáp ứng các yêu cầu sau:
Cung cấp một cơ chế cho phép người dùng đưa ra các đặc tả bằng ngôn ngữ
tự nhiên để gọi các dịch vụ web
Cung cấp cơ chế tự động gọi thực thi và xử lí kết quả trả về từ các dịch vụ web
Luận văn cũng sử dụng kiến trúc này để thực hiện một ứng dụng ví dụ: cập nhật động nội dung một trang web thông qua các kết quả thu thập tự động từ dịch vụ web có ngữ nghĩa
Trang 4MỤC LỤC
LỜI CẢM ƠN 2
TÓM TẮT LUẬN VĂN 3
MỤC LỤC 4
CHƯƠNG 1 TỔNG QUAN 6
1.1 Đặt vấn đề 6
1.2 Kiến trúc tổng quát và ứng dụng cập nhật động nội dung trang web 7
1.3 Mục tiêu và giới hạn đề tài 7
1.4 Cấu trúc của luận văn 8
CHƯƠNG 2: CƠ SỞ LÝ THUYẾT 9
2.1 Web ngữ nghĩa 9
2.2 Dịch vụ web 14
2.3 KIM 17
2.4 PROTON 20
CHƯƠNG 3 CÁC NGHIÊN CỨU LIÊN QUAN 23
3.1 Framework của luận văn đi trước 23
3.2 Chuyển đổi câu truy vấn thành đồ thị khái niệm 26
3.3 Chuyển đổi đồ thị khái niệm thành câu truy vấn SeRQL 35
CHƯƠNG 4 TỪ BÀI TOÁN THỰC TẾ ĐẾN KIẾN TRÚC HỆ THỐNG 44
4.1 Phân tích nhu cầu thực tế 44
4.2 Phương hướng thực hiện 45
4.3 Sơ đồ chi tiết hệ thống 47
4.4 So sánh với framework của luận văn đi trước 49
CHƯƠNG 5 ỨNG DỤNG CẬP NHẬT TRANG WEB ĐỘNG 52
5.1 Giới thiệu: 52
5.2 Kết quả hiện thực phía server 54
5.3 Kết quả hiện thực phía client 56
CHƯƠNG 6 THỬ NGHIỆM VÀ ĐÁNH GIÁ HỆ THỐNG 60
6.1 Cơ sở tri thức của KIM và ontology cho thử nghiệm 60
6.2 Kết quả thực nghiệm 60
6.3 Thảo luận về kết quả 61
CHƯƠNG 7 KẾT LUẬN 63
7.1 Kết quả đạt được 63
7.2 Hướng phát triển tương lai 64
THƯ MỤC THAM KHẢO 65
Trang 5DANH MỤC HÌNH
Hình 2.1 Liên kết ngữ nghĩa giữa các nguồn khác nhau trong Semantic Web 9
Hình 2.2 Kiến trúc web ngữ nghĩa (Semantic Web) 10
Hình 2.3 Kiến trúc dịch vụ web 14
Hình 2.4 Minh họa cho KIM 18
Hình 2.5 Hình minh họa cho các lớp trong PROTON 21
Hình 3.1: Sơ đồ chi tiết framework của luận văn đi trước 24
Hình 3.2 Hình minh họa cho đồ thị khái niệm 27
Hình 3.3 Đồ thị khái niệm có tham chiếu truy vấn 28
Hình 3.4 Xây dựng đường đi giữa hai lớp 30
Hình 3.5 Hợp nhất các đường đi 31
Hình 3.6 Thêm vào tham chiếu phát sinh để hình thành đường đi 32
Hình 3.7 Một khái niệm có hai cá thể 33
Hình 3.8 Nhiều khái niệm trên cùng một từ 34
Hình 3.9 Nhiều đường đi cho một cặp khái niệm/cá thể 35
Hình 3.10 Kiến trúc Sesame 36
Hình 3.11 Đồ thị khái niệm trong path expression 39
Hình 3.12 Đồ thị khái niệm cho ví dụ của giải thuật chuyển đổi 41
Hình 4.1 Sơ đồ chi tiết của hệ thống 47
Hình 4.2 So sánh 2 hệ thống cũ và mới 50
Hình 5.1 Ứng dụng cập nhật trang web động 53
Hình 5.2 Hoạt động của các module trong hệ thống 55
Hình 5.3 Tạo liên kết đến thực thể được truy vấn 57
Hình 5.4 Trang web có liên kết động sau khi được load lên 57
Hình 5.5 Trả về các kết quả theo yêu cầu truy vấn 58
Hình 5.6 Tạo liên kết đến thực thể được truy vấn 58
Hình 5.7 Web User Interface của KIM hiện ra sau khi nhấn vào link 59
Hình 6.1 Số lượng các khái niệm trong KB chuẩn của KIM 60
Trang 6CHƯƠNG 1 TỔNG QUAN
1.1 Đặt vấn đề
Hiện nay, với sự mở rộng của Internet, nhu cầu cập nhật trang web là một trong những nhu cầu thiết thực, đặc biệt là trên những trang web mà thông tin biến đổi liên tục và thường xuyên như trang web báo điện tử Tuy vậy, cách hiện thực trước nay cho việc cập nhật trang web động là người lập trình viên lập trình cho trang web cập nhật dựa trên một cơ sở dữ liệu Điều này đòi hỏi người xây dựng trang web phải thông hiểu lập trình cũng như phải tự mình tạo, quản lí và cập nhật một cơ
sở liệu cho ứng dụng Như vậy muốn xây dựng một trang web cập nhật động cần có kiến thức sâu của người xây dựng trang web và chi phí nhất định để duy trì và cập nhật cơ sở dữ liệu Điều này gây trở ngại rất lớn cho đại đa số người có nhu cầu thực sự về xây dựng trang web tự động cập nhập như nhà báo, nhà biên tập… Đồng thời cách tiếp cận này cũng hạn chế về nội dung được cập nhật trong cơ sở dữ liệu cục bộ, không có sự tương tác với các nguồn thông tin từ bên ngoài
Hướng tiếp cận có thể giải quyết vấn đề này là dựa trên kiến trúc hướng dịch vụ hướng ngữ nghĩa (SSOA - Semantic Service Oriented Architecture) Người dùng
sử dụng một dịch vụ web ngữ nghĩa được cung cấp từ xa Họ không cần phải xây dựng cơ sở dữ liệu mà chỉ cần cung cấp yêu cầu ngữ nghĩa của họ Tuy vậy hướng tiếp cận này vẫn đòi hỏi người dùng cần biết các kĩ thuật để gọi dịch vụ và cung cấp thông tin ngữ nghĩa
Ví dụ: trang web thể thao muốn cập nhật động tỉ số các trận bóng đá, mặc dù đã
có dịch vụ web cung cấp các thông tin này, người soạn trang web này vẫn phải lập trình các thủ tục cần thiết để gọi dịch vụ, cung cấp các thông số, sau đó xử lí kết quả trả về và cho hiển thị lên trang web Các công việc này gây lúng túng cho người dùng và hạn chế khả năng miêu tả yêu cầu của họ
Mục tiêu của luận văn là xây dựng một kiến trúc tổng quát giúp người dùng có thể gọi các dịch vụ thông qua ngôn ngữ tự nhiên và nhận được kết quả của dịch vụ mong muốn Luận văn cũng sẽ hiện thực một ứng dụng ví dụ dựa trên kiến trúc này:
Trang 7Người dùng khi soạn thảo trang web sẽ sử dụng ngôn ngữ tự nhiên để yêu cầu cung cấp các đường link động cho trang web của mình mà không cần biết về hiện thực bên dưới
Cách tiếp cận này làm cho việc sử dụng các dịch vụ ngữ nghĩa trong một ứng dụng cụ thể như xây dựng trang web tự động trở nên thân thiện với người sử dụng, đồng thời cơ sở dữ liệu để cập nhật là do các nhà dịch vụ cung cấp, giúp người dùng tiết kiệm chi phí cũng như không cần có kiến thức sâu về tin học
1.2 Kiến trúc tổng quát và ứng dụng cập nhật động nội dung trang web
Dựa trên các vấn đề đã được nêu ra ở trên, trước hết luận văn sẽ xây dựng một kiến trúc tổng quát cho phép người dùng gọi các dịch vụ web thông qua miêu tả bằng ngôn ngữ tự nhiên Từ kiến trúc này, chúng ta hiện thực ứng dụng cho phép cập nhật động nội dung trên một trang web bằng các dịch vụ web có ngữ nghĩa Người soạn thảo trang web sẽ miêu tả yêu cầu nội dung động của mình bằng ngôn ngữ tự nhiên và lưu kết quả soạn thảo lại Mỗi lần trang web được tải lên (load), hệ thống sẽ tự động gọi các dịch vụ web ngữ nghĩa tương ứng với yêu cầu người sử dụng, nhận kết quả trả về và cập nhật nội dung cho trang web
1.3 Mục tiêu và giới hạn đề tài
Mục tiêu:
Xây dựng hệ thống cho phép tự động cập nhật nội dung một trang web từ các yêu cầu của người sử dụng Các yêu cầu này được nhập dưới dạng ngôn ngữ tự nhiên (tiếng Anh) đơn giản Chúng sẽ được đưa đến một dịch vụ web khép kín để
xử lí và trả về kết quả cập nhật cho trang web Đề tài này có thừa kế lại mô hình lí thuyết của một đề tài nghiên cứu trước[8] và giải thuật l ý thuyết phân tích câu truy vấn tự nhiên đơn giản[2]
Trang 8Giới hạn:
Ontology sử dụng trong đề tài là một ontology rút gọn từ PROTON – ontology được cung cấp sẵn của KIM Từ đó kho ngữ liệu tương ứng sẽ xây dựng ở quy mô thử nghiệm
Các yêu cầu của người sử dụng là các câu tiếng Anh đơn giản
1.4 Cấu trúc của luận văn
Luận văn có 7 chương bao gồm các nội dung sau:
Chương 1 giới thiệu tổng quan về đề tài của luận văn cũng như mục tiêu đề
ra của luận văn
Chương 2 giới thiệu các khái niệm và lý thuyết mà luận văn có sử dụng
Chương 3 nêu các công trình nghiên cứu mà luận văn kế thừa
Chương 4 miêu tả cấu trúc tổng quát giúp người dùng gọi dịch vụ thông qua ngôn ngữ tự nhiên
Chương 5 về hiện thực ứng dụng cụ thể: cập nhập trang web động
Chương 6 về thử nghiệm và đánh giá ứng dụng trên dữ liệu thực tế
Chương 7 tóm lại và tổng kết luận văn
Trang 9CHƯƠNG 2: CƠ SỞ LÝ THUYẾT
Semantic Web là một mạng lưới các thông tin được liên kết sao cho chúng có thể được xử lý dễ dàng bởi các máy tính ở phạm vi toàn cầu Nó được xem là cách
mô tả thông tin rất hiệu quả trên mạng toàn cầu (World Wide Web - WWW) và cũng được xem là một cơ sở dữ liệu có khả năng liên kết toàn cầu Nhờ vậy, việc tìm kiếm thông tin sẽ thu được kết quả tốt hơn
Ý tưởng liên kết nhiều nguồn khác nhau (tài liệu, hình ảnh, khái niệm, …) cho phép chúng ta mở rộng web thành một môi trường mới với các mối quan hệ mới
(như hasLocation, worksFor, isAuthorOf, dependsOn, …) giữa các nguồn dữ liệu,
tạo ra mối liên hệ ngữ cảnh, điều mà web hiện tại chưa làm được
Trang 10Hình 2.1 minh họa mối liên kết ngữ nghĩa giữa các nguồn khác nhau trong Semantic Web Hình này mô tả các mối quan hệ của một phần mềm (Software) với
các thành phần khác, ví dụ như Software có tài liệu hướng dẫn (hasManual) là một
Document, Document này lại dựa trên (isBasedOn) một Document khác, một Document có tác giả (hasAuthor) là một người (Person), và một người sẽ sống tại
(livesAt) một nơi nào đó (Place), …
2.1.2 Kiến trúc
Semantic Web là một tập hợp, một chồng (stack) các lớp[21] Tất cả các lớp của Semantic Web được sử dụng để đảm bảo độ an toàn và giá trị thông tin trở nên tốt nhất
Trang 11cập đến thường xuyên hơn, nhưng URI được đề cập đến như một khái niệm trong Semantic Web để chỉ các tài nguyên
Lớp XML
Cùng với các định nghĩa về không gian tên (namespace) và lược đồ (schema), lớp XML đảm bảo rằng chúng ta có thể tích hợp các định nghĩa Semantic Web với các chuẩn khác dựa trên XML
Lớp RDF và RDF Schema (RDFS)
Lớp RDF và RDF Schema giúp chúng ta có thể tạo các phát biểu (statement) để
mô tả các đối tượng với những từ vựng và cú pháp của URI Ðây là lớp mà chúng ta
có thể gán các kiểu (type) cho các tài nguyên và liên kết, và cũng là lớp quan trọng nhất trong kiến trúc Semantic Web
Ban đầu, web được tạo ra để con người thao tác: đọc, hiểu, … Mặc dù máy có thể đọc được mọi thứ trên web, nhưng nó không hiểu được dữ liệu trên web Giải pháp được đưa ra là dùng siêu dữ liệu (metadata) để mô tả dữ liệu trên web để máy
có thể hiểu được chúng Siêu dữ liệu là một dạng dữ liệu dùng để mô tả dữ liệu khác Hay nói cách khác, siêu dữ liệu là những thông tin mô tả tài nguyên trên web RDF (Resource Description Framework) là nền tảng của Semantic Web và xử lý metadata RDF cho phép trao đổi thông tin giữa các ứng dụng trên web mà máy có thể hiểu được
Trang 12Cấu trúc cơ bản của một phát biểu RDF rất đơn giản, gồm 3 thành phần:
Subject: Chủ thể - là cái mà chúng ta đề cập, thường được nhận diện bởi một URI
Predicate: Thuộc tính của chủ thể, có kiểu metadata (ví dụ như tiêu đề, tác giả, ), cũng có thể được xác định bởi một URI
Object: Giá trị của thuộc tính (ví dụ: một người có tên Eric Miller)
Tập hợp các RDF statement được lưu dưới dạng cú pháp của XML, còn được gọi là RDF/XML
Tuy nhiên, mô hình dữ liệu RDF không cung cấp những cơ chế cho việc khai báo các thuộc tính, cũng như không cung cấp bất kỳ cơ chế nào để có thể định nghĩa
ra những quan hệ giữa các thuộc tính và các tài nguyên Ðó sẽ là vai trò của RDF schema, hay nói cách khác RDF schema được dùng để định nghĩa các tài nguyên và thuộc tính cũng như các quan hệ qua lại giữa tài nguyên với tài nguyên, giữa thuộc tính với thuộc tính, và giữa tài nguyên với thuộc tính
RDF schema là một tập những từ khoá mà qua đó RDF schema cho phép người
dùng định nghĩa bộ từ vựng cụ thể cho tài liệu RDF (ví dụ như: hasName, hasPrice,
authorOf, …) và định nghĩa các quan hệ của nó đến các đối tượng liên quan Chẳng
hạn như từ hasName ta định nghĩa quan hệ của nó trên hai đối tượng:
„http://www.w3c.org/employee/id1321‟ và “Jim Lerners” như sau:
hasName („http://www.w3c.org/employee/id1321‟,“Jim Lerners”)
Trang 13niệm cơ bản trong một lĩnh vực và các mối liên hệ giữa chúng mà máy có thể hiểu được
Một số lý do cần phát triển một ontology:
Ðể chia sẻ những hiểu biết chung về cấu trúc thông tin
Cho phép tái sử dụng tri thức lĩnh vực (domain knowledge)
Làm cho các giả thuyết về lĩnh vực được tường minh
Tách biệt tri thức lĩnh vực (domain knowledge) ra khỏi tri thức thao tác (operational knowledge)
Phân tích tri thức lĩnh vực
Lớp Digital Signature
Lớp Digital Signature dùng để xác định chủ thể của tài liệu (ví dụ: tác giả của một tài liệu hay một lời tuyên bố)
Các lớp Logic, Proof, Trust
Các lớp này còn đang trong giai đoạn nghiên cứu và phát triển Lớp Logic cho phép viết ra các luật (rule), trong khi đó, lớp Proof thi hành các luật và cùng với lớp Trust đánh giá nhằm quyết định ứng dụng nên hay không nên tin tưởng/ chấp nhận (trust) chứng cứ (proof) – format font
Trang 142.2 Dịch vụ web
2.2.1 Giới thiệu
Dịch vụ web là được định nghĩa bởi W3C là “một hệ thống phần mềm được thiết kế để hỗ trợ việc tương tác giữa máy và máy qua mạng máy tính” Dịch vụ web thường chỉ là một giao diện lập trình web (Web API) mà có thể được truy xuất thông qua một mạng máy tính, chẳng hạn mạng Internet, và thực thi trên một hệ thống từ xa có chứa dịch vụ được yêu cầu
2.2.2 Kiến trúc
Kiến trúc cơ bản của dịch vụ web bao gồm 3 thành phần chính: Service Requester, Service Broker và Service Provider Vai trò của các thành phần được thể hiện ở hình 2.3
Figure 3Hình 2.3 Kiến trúc dịch vụ web
Trang 15 Service Provider tạo dịch vụ web và đưa ra (publish) interface của dịch
vụ web Interface này được biểu diễn bằng WSDL và gửi đến Service Broker
Service Broker nắm giữ thông tin về tất cả các dịch vụ được cung cấp và kết nối các dịch vụ này đến các Service Requester có nhu cầu phù hợp Service Broker sử dụng UDDI để lưu trữ và khai phá các dịch vụ web
Service Requester gửi yêu cầu của mình đến Service Broker bằng WSDL
và sau đó kết nối (bind) với Service Provider mà Service Broker cung cấp
để sử dụng các dịch vụ thông qua SOAP
Các thành thần giao tiếp với nhau bằng các chuẩn được giới thiệu sau đây
2.2.2.1 SOAP
SOAP (Simple Object Access Protocol)[22] là một giao thức đơn giản dựa trên XML cho phép ứng dụng trao đổi thông tin qua HTTP Các đặc điểm của SOAP:
SOAP là một định dạng cho việc gửi các thông điệp
SOAP được thiết kế để giao tiếp thông qua Internet
SOAP không lệ thuộc platform
SOAP không lệ thuộc vào ngôn ngữ
SOAP đơn giản và khả mở rộng
SOAP cho phép vượt qua tường lửa
2.2.2.2 WSDL
WSDL (Web Services Description Language)[24] là một ngôn ngữ dựa trên XML
để miêu tả dịch vụ web và cách thức để truy cập chúng Các đặc điểm của WSDL:
WSDL dùng để miêu tả dịch vụ web – định dạng thông điệp, kiểu dữ liệu, giao thức truyền… giữa requester và provider
WSDL cũng được dùng để định vị các dịch vụ web
Trang 16 WSDL là một chuẩn của W3C
2.2.2.3 UDDI
UDDI (Universal Description, Discovery and Integration)[23] là một dịch vụ thư mục giúp các tổ chức kinh doanh có thể đăng kí và tìm kiếm dịch vụ Web Các đặc điểm của UDDI:
UDDI là một thư mục cho việc lưu trữ thông tin về dịch vụ web
UDDI là một thư mục của các interface cho dịch vụ web được miêu tả bởi WSDL
UDDI liên lạc thông qua SOAP
UDDI được tích hợp trong NET platform của Microsoft
2.2.3 Sự tiện dụng của dịch vụ Web so với cách phát triển ứng dụng bình thường
Ưu điểm của dịch vụ web so với cách phát triển ứng dụng bình thường là ai cũng có thể sử dụng các dịch vụ web do các nhà cung cấp dịch vụ đưa ra theo một giao thức định trước, bất kể người phát triển sử dụng hệ thống nào, ngôn ngữ lập trình nào Web service có thể xem là một module phần mềm linh hoạt có thể lắp ráp vào bất cứ nơi nào, giúp người sử dụng không cần phải tự xây dựng tất cả các module trong ứng dụng của mình Ví dụ: người dùng phát triển một ứng dụng soạn thảo văn bản Ứng dụng này đòi hỏi có hàm kiểm tra lỗi chính tả Nếu phát triển ứng dụng bình thường, người phát triển cần xây dựng được một module kiểm tra lỗi chính tả - đòi hỏi thời gian và kiến thức chuyên môn - hoặc tích hợp một phần mềm kiểm tra lỗi chính tả có sẵn vào phần mềm của mình – không dễ dàng nếu phần mềm được phát triển trên một hệ thống khác, một ngôn ngữ khác Ngày nay, công việc kiểm tra lỗi chính tả có thể sử dụng một dịch vụ web phát triển sẵn Tất cả công việc của người phát triển ứng dụng là cung cấp thông số và gọi dịch vụ từ xa theo một giao thức để kiểm tra lỗi chính tả Điều này hết sức tiện lợi vì cách thức gọi dịch vụ web không phục thuộc vào hệ thống và ngôn ngữ Ngoài ra, tính tiện lợi
Trang 17của dịch vụ web còn ở chỗ môi trường hoạt động của nó: Internet Người phát triển cũng như sử dụng ứng dụng có thể gọi dịch vụ mọi lúc, mọi nơi chỉ với một chi phí thấp
Dịch vụ web là một bước phát triển tất yếu để chuyên biệt hóa công việc, mang lại sự hiệu quả và tránh lãng phí cho người dùng Tuy vậy, đối với người phát triển và sử dụng thông thường, họ vẫn cần phải nắm được các kiến thức và cách thức lập trình để gọi dịch vụ web Hướng đi của luận văn cũng nhằm giải quyết được rào cản kĩ thuật này cho người sử dụng
2.3 KIM
KIM [3] là một nền tảng cung cấp một cơ sở hạ tầng mới cho việc quản lí tri thức và thông tin (Knowledge and Information Management - KIM) và phục vụ cho việc gán ngữ nghĩa tự động, đánh chỉ số, và rút trích những nội dung không
có cấu trúc hay bán cấu trúc Các ứng dụng trực tiếp của KIM là:
Tạo sinh meta-data cho web ngữ nghĩa, điều này cho phép siêu liên kết và mô hình hóa cũng như dẫn hướng cấp cao
Quản lí tri thức, tăng cường sự hiệu quả của phép đánh chỉ số hiện có, các ứng dụng về rút trích, phân lớp và lọc dữ liệu
KIM được giới thiệu với ba chức năng:
Một nền tảng có mục đích và cách sử dụng tương tự như RDBMS và hệ thống KM
Một phần mở rộng phát triển bới bên thứ ba đi kèm trong các sản phẩm
KM lớn hơn (mô hình OEM)
Một dịch vụ web, được cung cấp từ xa với cài đặt và chi phí bảo trì tối thiểu
KIM phân tích văn bản và nhận dạng những tham khảo đến các thực thể (như con người, tổ chức, vị trí, ngày tháng) Sau đó nó cố gắng so trùng các tham khảo
Trang 18đó với một thực thể đã biết, có một URI và mô tả duy nhất Hoặc là nó sẽ tạo tự động một URI và mô tả cho thực thể đó Cuối cùng, tham khảo trong văn bản được đánh dấu với URI của thực thể Chúng ta gọi quá trình xử lí này (cũng như kết quả của xử lí) là đánh dấu ngữ nghĩa (semantic annotation) Meta-data như thế này có thể được sử dụng cho việc đánh chỉ số, rút trích, mô hình hóa và tự động siêu liên kết cho văn bản Hình 2.4 cho thấy cách KIM hoạt động đối với một văn bản cụ thể
KIM sẽ tự động nhận dạng những thực thể “XYZ”, “Bulgaria”… rồi liên kết đến các khái niệm đã có trong ontology Nếu thực thể là chưa biết, KIM sẽ tạo mới một URI và mô tả cho thực thể Cụ thể là “XYZ” sẽ có các property: type là Company, establOn là “03/11/1978” và có quan hệ locatedIn với London;
“Bulgaria” có type là Country… Cuối cùng, tham khảo trong văn bản được đánh dấu với URI cụ thể của thực thể, văn bản đã được đánh dấu ngữ nghĩa, các thông tin trong văn bản được đánh chỉ số, rút trích và lưu lại trong KB của KIM
Để cho phép tự phát triển ứng dụng dễ dàng hơn, KIM được trang bị với một ontology bậc cao (upper-level ontology) PROTON với khoảng 250 lớp và 100
Trang 19thuộc tính Hơn nữa, một cơ sở tri thức (KIM KB), có sẵn khoảng 200000 mô tả thực thể, được đi kèm trong KIM Vai trò của nó là một tri thức nền tảng (giống như một nền văn hóa chung của con người) cho việc tập hợp gần như đầy đủ các thực thể quan trọng khát quát nhất – mà những thực thể này không được đưa vào các văn bản do chúng được coi là quá phổ biến Vì lý do này, mô tả của chúng rất khó để tự động rút ra
Từ một góc nhìn kĩ thuật, kiến trúc này cho phép những ứng dụng dựa trên KIM thực hiện đánh dấu ngữ nghĩa tự động, rút trích nội dung, dựa trên ràng buộc ngữ nghĩa, cũng như truy vấn và chỉnh sửa những ontology và cơ sở tri thức nằm bên dưới[3]
Dịch vụ web của KIM API đại diện cho một tầng tương hỗ (interoperability) cho việc truy cập các chức năng của server Chúng cho phép truy cập từ web và độc lập ngôn ngữ Người sử dụng KIM đã hiện thực thành công client bằng C#, Perl, Ruby và Java
Có năm dịch vụ web cho phép truy cập đến những KIM API tương ứng là:
Dịch vụ web API kho chứa ngữ nghĩa (Semantic Repository API web service) chứa những phương thức cho truy vấn và chỉnh sửa những kho chứa ngữ nghĩa nằm bên dưới
Dịch vụ web API kho chứa văn bản (Document Repository API web service) chứa những phương thức cho truy vấn và chỉnh sửa những văn bản KIM trong các kho chứa văn bản nằm ở bên dưới Dịch vụ này có hai sự bổ sung
vào các phương thức DocumentRepositoryAPI chuẩn Chúng là một phần của các chức năng được cung cấp bởi CoreDbAPI Cả hai chỉ có thể truy cập
nếu COREDB được bật lên
Dịch vụ web API thực thể (Entity API web service) chứa những phương thức phục vụ như một tầng trừu tượng bên trên kho ngữ nghĩa và cho phép thao tác trực tiếp với các thực thể
Trang 20 Dịch vụ web API truy vấn (Query API web service) chứa những phương thức phục vụ như một tầng trừu tượng bên trên ngữ nghĩa và kho chứa văn bản
Dịch vụ web API đánh dấu ngữ nghĩa (Semantic Annotation API web service) chứa những phương thức cho việc đánh dấu ngữ nghĩa trên dữ liệu thô hay cấu trúc văn bản KIM
Hiện tại, PGS.TS Cao Hoàng Trụ cùng các cộng sự tại khoa Công nghệ Thông tin, trường Đại học Bách Khoa Thành phố Hồ Chí Minh đã và đang phát triển VN-KIM, một hệ thống được thiết kế dựa trên KIM VN-KIM là hệ thống quản lý tri thức và thông tin cho các thực thể có tên ở Việt Nam, là hệ thống đầu tiên ở Việt Nam thực hiện việc khai phá, phân loại, đánh dấu ngữ nghĩa và lưu trữ các thông tin trên web theo các thực thể có tên VN-KIM đã có những cải tiến và mở rộng để phù hợp với việc nhận diện các thực thể có tên thuộc ngôn ngữ tiếng Việt Ngoài ra, VN-KIM còn cho phép truy hồi thông tin gần đúng và bằng đồ thị khái niệm[25]
2.4 PROTON
PROTON là viết tắt của Proto Ontology[6], là một ontology bậc cao cơ bản
(Basic Upper-Level Ontology) trong phạm vi của dự án SEKT PROTON được
sử dụng như một tri thức nền tảng để sinh ontology (ontology greneration) Nó được phát triển từ ontology KIMO – ontology đã được tạo ra và sử dụng trong phạm vi của KIM platform cho việc đánh dấu ngữ nghĩa, đánh chỉ số và rút trích Ontology PROTON chứa khoảng 300 lớp và 100 thuộc tính, cung cấp các khái niệm khái quát cần thiết cho một lĩnh vực rộng các ứng dụng, bao gồm cả việc đánh dấu ngữ nghĩa, đánh chỉ số và rút trích thông tin từ văn bản Nguyên tắc thiết kế PROTON có thể được tóm tắt như sau:
(i) Không phụ thuộc vào domain
(ii) Định nghĩa logic light-weight (light-weight logical definitions)
Trang 21(iii) Liên kết với các chuẩn phổ biến
(iv) Bao phủ tốt các thực thể có tên và lãnh vực cụ thể (con người, tổ chức, vị
trí, con số, ngày tháng, …)
PROTON được mã hóa dưới dạng OWL Lite[5]
Trang 22Để đáp ứng được các kịch bản sử dụng và bảo đảm được sự dễ hiểu, PROTON được chia làm bốn thành phần:
System module: chứa vài thành phần căn bản ở mức meta (5 lớp và 5 thuộc tính) Nó giới thiệu khái niệm về “thực thể” (entity), thực thể có thể
có các bí danh (alias) Những thành phần căn bản ở mức này thường phải được viết mã cứng vào các ứng dụng được trên ontology Thành phần này
có thể được coi như là một ontology ứng dụng Thành phần system của
PROTON được tham khảo đến thông qua tiếp đầu ngữ “protons:”
Top module: mức khái niệm cao nhất, tổng quát nhất, bao gồm 20 lớp
Nó bảo đảm sự cân bằng tốt về mặt tiện ích, không phụ thuộc domain, và
sự dễ hiểu, dễ sử dụng Lớp trên cùng thường là mức tốt nhất để thiết lập
sự liên kết với những ontology và schemata khác Thành phần top của
PROTON được tham khảo đến thông qua tiếp đầu ngữ “protont:”
Upper module: gồm trên 200 lớp chung của các thực thể, mà các lớp này thường xuất hiện trong nhiều domain Thành phần upper của PROTON
được tham khảo đến thông qua tiếp đầu ngữ “protonu:”
KM (Knowledge Management) module: gồm 38 lớp của các thực thể được chuyên biệt cho những công việc và ứng dụng về quản lí tri thức điển hình Thành phần KM thật ra là ontology SKULO trước đây [6], được phát triển hơn và tích hợp vào trong PROTON Thành phần upper của PROTON được
tham khảo đến thông qua tiếp đầu ngữ “protonkm:”
Chú ý: trong các phần sau, ta sử dụng domain ontology là PROTON để đưa
ra và giải thích các ví dụ
Trang 23CHƯƠNG 3 CÁC NGHIÊN CỨU LIÊN QUAN
3.1 Framework của luận văn đi trước
3.1.1 Giới thiệu
Luận văn đi trước của tác giả Huỳnh Tấn Khải [8] có cùng đề tài với luận văn này : “Cập nhật động nội dung trang web bằng các dịch vụ web có ngữ nghĩa” Cách tiếp cận của luận văn đi trước là sử dụng framework có sẵn WSMX để tự động cập nhật thông tin, bao gồm quá trình từ lúc tạo ra trang web đến khi trang web được tải (load) Người dùng chỉ cần mô tả thông tin cần cập nhật động, còn các phần việc còn lại sẽ do hệ thống (framework) đảm nhận
3.1.2 Kiến trúc của framework
Hình 3.1 trình bày sơ đồ chi tiết của framework của luận văn đi trước
Framework gồm có 2 phần chính:
Thành phần phía người dùng (Client Module): Hiện thực một chức năng mở
rộng (plug-in) cho một trình soạn thảo web (web editor), nó cho phép đặc tả các yêu cầu thực thi dịch vụ (goal) với mô tả gần với ngôn ngữ tự nhiên Web editor này có chức năng sinh tự động ra các đoạn mã WSML mô tả goal, đoạn mã để gọi thực thi yêu cầu và nhận kết quả trả về để cập nhật vào nội dung trang web
Trang 24Client Module Giai đoạn Design
Web Editor
yêu cầu người dùng
Mã gọi thực thi yêu cầu người dùng
Nơi cần cập nhật động nội dung
Message Processor
Discovery Engine
Web Service Invoker
HTML Convertor
Server Module
Giai đoạn Loading
Nơi cần cập nhật động nội dung
Mã WSML mô tả yêu cầu người dùng
Mã gọi thực thi yêu cầu người dùng
Thông điệp gọi thực thi yêu cầu
Goal
Web service phù hợp với Goal (Selected_WS)
Kết quả trả
về (Result)
Danh sách tham
Trang 25Thành phần thực thi phía Server (Server Module): thực hiện các chức năng
chính trong việc khai phá dịch vụ, gọi thực thi dịch vụ và nhận kết quả trả về khi chúng ta thực thi một yêu cầu Trong phần này có các khối chức năng chính như sau:
Message Processor: Thành phần này dùng để phân tích message mà khi
trang web được load, nó gởi sang để thực thi yêu cầu Việc phân tích này để tách ra nội dung của goal và các tham số của nó Thông tin về goal sẽ được truyền cho thành phần Discovery Engine để thực hiện việc tìm kiếm các dịch
vụ web đáp ứng được goal
Discovery Engine: Thành phần này nhận đầu vào là goal từ thành phần
Message Processor gởi sang và thực hiện việc tìm kiếm các dịch vụ web có khả năng đáp ứng được goal Việc so trùng để tìm kiếm dịch vụ web đáp ứng goal này phải được thực hiện so trùng về mặt ngữ nghĩa, khắc phục các nhược điểm mà các hệ thống đã khảo sát ở trên như việc bỏ sót dịch vụ hay chọn sai dịch vụ
Web Service Invoker: Thành phần này có chức năng gọi thực thi dịch vụ
web đã được trả về từ Discovery Engine Kết quả trả về của việc gọi thực thi này được dùng để cập nhật cho nội dung của trang web
HTML Convertor: Thành phần này nhận kết quả trả về từ thành phần Web
Service Invoker Kết quả trả về này không phải luôn luôn ở dạng chuẩn HTML nên HTML Convertor phải chuyển nó sang dạng chuẩn HTML để cập nhật vào nội dung trang web
Service Registry: Thành phần này cho phép các nhà cung cấp dịch vụ đăng
ký thông tin về dịch vụ của họ vào framework Framework sẽ lưu trữ thông tin này trong kho (Repository) để phục vụ cho việc tìm kiếm và so trùng
Repository: Repository là kho chứa các dịch vụ của các nhà cung cấp dịch vụ
đăng ký vào framework Các dịch vụ mà các nhà cung cấp dịch vụ đăng ký
Trang 26sẽ được lưu trữ vào đây mà phục vụ cho mục đích khai phá và gọi thực thi dịch vụ
Service Provider: Đây là thành phần bên ngoài framework Các Service
Provider là các nhà cung cấp dịch vụ Để framework có thể khai phá và gọi thực thi các dịch vụ web của một nhà cung cấp dịch vụ thì nhà cung cấp dịch
vụ này phải đăng ký các dịch vụ mà họ có vào framework Việc đăng ký này
được thực hiện thông qua thành phần Service Registry (đã giới thiệu ở trên)
3.1.3 Nhận xét về framework
Framework của luận văn đi trước đã thực hiện được cơ bản những yêu cầu đề
ra Tuy vậy nó vẫn có những hạn chế sau:
Người dùng phải đặc tả các yêu cầu thực thi dịch vụ với các khái niệm thực thể, loại thực thể… vẫn gây ra rào cản kĩ thuật đối với người sử dụng
Hệ thống khá phức tạp, client cần được cung cấp ontology để phân tích goal
và đưa yêu cầu của goal đến server để tìm dịch vụ tương ứng
Client được hiện thực chỉ đáp ứng được một dịch vụ theo yêu cầu người dùng (ở luận văn đi trước là các bài báo liên quan đến thực thể được đặc tả) Nếu muốn thực hiện dịch vụ khác thì phải thiết kế lại yêu cầu của client cũng như tạo và đăng kí dịch vụ tương ứng
Luận văn này sẽ tiến tới việc giải quyết các hạn chế nêu trên
3.2 Chuyển đổi câu truy vấn thành đồ thị khái niệm
Để xử lí các câu truy vấn theo ngôn ngữ tự nhiên, Conceptual Graph (CG) được coi như là một kĩ thuật hữu hiệu để nắm bắt và thể hiện ngữ nghĩa bằng một cấu trúc ngôn ngữ học Tuy vậy sự chuyển đổi tự động từ câu truy vấn bằng ngôn ngữ tự nhiên sang CG vẫn là một vấn đề phức tạp Phần này sẽ trình bày khái niệm
cơ bản của đồ thị khái niệm và cách thức chuyển đổi câu truy vấn bằng ngôn ngữ tự nhiên sang đồ thị khái niệm theo hướng sử dụng domain ontology
Trang 273.2.1 Đồ thị khái niệm
Đồ thị khái niệm (Conceptual Graph - CG) là một hệ thống logic dựa trên đồ thị tồn tại của Charles Sanders Peirce và mạng ngữ nghĩa của trí tuệ nhân tạo Chúng biểu diễn ý nghĩa ở một dạng chính xác, khả đọc bởi con người, và dễ xử lí trong tính toán Với khả năng ánh xạ trực tiếp đến ngôn ngữ, đồ thị khái niệm là một ngôn
ngữ trung gian để dịch những dạng thức hướng máy tính (computer-oriented) từ
ngôn ngữ tự nhiên và ngược lại Với khả năng biểu diễn trực quan, chúng được sử dụng như một ngôn ngữ khả đọc nhưng có thiết kế chính tắc và rõ ràng CG đã được hiện thực trong nhiều dự án trong rút trích thông tin, thiết kế cơ sở dữ liệu và xử lí ngôn ngữ tự nhiên [1]
Đồ thị khái niệm là một đồ thị phân đôi có các đỉnh khái niệm (concept vertices) xen kẽ với các đỉnh quan hệ (relation vertices) và các cạnh liên kết các đỉnh quan hệ với các đỉnh khái niệm Mỗi đỉnh khái niệm được vẽ dưới dạng một hình chữ nhật,
có nhãn là loại khái niệm (concept type) và tham chiếu của khái niệm đó (concept referent) Nó đại diện cho một thực thể có loại khái niệm và tham chiếu tương ứng với nhãn đó Mỗi đỉnh quan hệ được vẽ dưới dạng hình oval, có nhãn là loại quan
hệ (relation type), đại diện cho một quan hệ của các thực thể có đại diện là các đỉnh khái niệm liên kết với nó Để ngắn gọn, ta có thể gọi đỉnh khái niệm và đỉnh quan
hệ là khái niệm và quan hệ một cách tương ứng Các khái niệm liên kết với cùng một quan hệ được gọi là các khái niệm liền kề (neighbour concepts) của quan hệ Mỗi cạnh có thể có hướng
Person: James JobPosition: CEO
hasPosition
Figure 7 Hình 3.2 Hình minh họa cho đồ thị khái niệm
Trang 28Ở ví dụ hình 3.2, đồ thị khái niệm nói lên “James has CEO position” Cá thể James và CEO được gọi là tham chiếu cá thể (individual referents) của khái niệm
Person và JobPosition tương ứng.Trong cách viết bằng chữ, khái niệm và quan hệ
có thể được viết trong ngoặc vuông và ngoặc tròn một cách tương ứng như sau:
[Person: James]→(hasPosition)→[JobPosition: CEO]
Đồ thị khái niệm cũng là một dạng thức hiệu quả để biểu diễn câu truy vấn bằng ngôn ngữ tự nhiên Hình 3.3 cho thấy đồ thị khái niệm biểu diễn câu truy vấn
“Find the person who works in Dell” Kí hiệu “?” chỉ ra một tham chiếu truy vấn (query referent) của đồ thị khái niệm, biểu diễn đối tượng sẽ được tìm kiếm Kí hiệu
“*” chỉ ra một tham chiếu phát sinh (genetic referent), nghĩa là không có một cá thể
cụ thể nào của khái niệm JobPosition được nêu ra tường minh trong câu truy vấn
3.2.2 Bộ sinh tự động các câu truy vấn bằng đồ thị khái niệm
Phần này nói về kĩ thuật xây dựng bộ sinh tự động các câu truy vấn bằng đồ thị khái niệm từ những kiến thức được lưu trữ trong domain ontology Kĩ thuật này được trình bày trong bài báo của TS Quản Thành Thơ[2] Tiến trình sinh tự động bao gồm hai bước:
Sinh khái niệm (Concept Generation) – Bước này nhận diện các khái niệm và
cá thể trong câu truy vấn và chuyển các khái niệm và cá thể đã được nhận diện thành các nốt khái niệm (concept nodes) của đồ thị khái niệm
Xây dựng quan hệ (Relation Construction) – Bước này xây dựng các nốt quan hệ giữa các nốt khái niệm dựa trên domain ontology để đạt được đồ thị
Trang 29khái niệm cuối cùng Trong lúc xây dựng, vài nốt khái niệm hay nốt quan hệ
sẽ được tạo ra và thêm vào đồ thị khái niệm cuối cùng
3.2.2.1 Sinh khái niệm
Bước này nhằm phân tích câu truy vấn được đưa vào để định dạng các khái niệm và cá thể Domain ontology có chứa các khái niệm và cá thể đã được định nghĩa, nó cung cấp một cơ chế mạnh mẽ để nhận dạng các khái niệm và cá thể một cách tự động từ một câu truy vấn Ta xem xét ví dụ sau:
(Q1): “Where is the location of Microsoft company?”
Sử dụng ontology được cung cấp, ta có thể nhận dạng khái niệm Location và
Company và cá thể Microsoft của lớp Company từ câu truy vấn
Chú ý rằng khi xây dựng domain ontology, ta có thể định nghĩa một bộ từ vựng ontology giúp cho việc nhận dạng các từ khóa khác nhau có thể liên quan đến những khái niệm và cá thể nhất định Ví dụ, ta có thể định nghĩa từ hỏi “Where” nên
tham chiếu đến một nơi chốn – Location, và khái niệm Company có thể được tham chiếu bởi những từ đồng nghĩa như là Corporation, Organization, … Do vậy nếu câu truy vấn được đổi sang một dạng khác như là “Where is Microsoft
Corporation?” thì các khái niệm và cá thể vẫn được nhận dạng tương tự
Sau khi nhận dạng các khái niệm và cá thể trong một câu truy vấn, ta sẽ gán chúng vào các nốt khái niệm tương ứng trong đồ thị khái niệm cuối cùng Để làm điều này, các luật heuristic sau đây được sử dụng:
Một cá thể sẽ được gán như là một tham chiếu cá thể
Một khái niệm sẽ được gán như là một tham chiếu truy vấn nếu không có
cá thể nào của khái niệm được nhận dạng trong câu truy vấn
Do đó, trong câu query (Q1), cá thể Microsoft sẽ được gán là một tham chiếu
cá thể Giữa hai khái niệm Position và Company, chúng ta chỉ giữ lại khái niệm
Position là tham chiếu truy vấn vì khái niệm Company đã có cá thể tương ứng của
nó – Microsoft – được tìm thấy trong câu truy vấn
Trang 30Xét câu truy vấn khác:
(Q2): “List all the persons who have Manager position in Microsoft?”
Với ontology cho trước, các khái niệm được định dạng là Person và
JobPosition, các cá thể là Manager và Microsoft Vì Manager là cá thể của khái
niệm JobPosition nên khái niệm JobPosition sẽ không được xét là tham chiếu truy vấn Cho nên, chỉ có một tham chiếu truy vấn là Person và hai tham chiếu cá thể
Manager và Microsoft được định dạng trong câu truy vấn này
3.2.2.2 Xây dựng các mối quan hệ
Như đã nói ở phần trên, các tham chiếu truy vấn và tham chiếu cá thể đã nhận diện sẽ được gán tương ứng vào các nốt khái niệm trong đồ thị khái niệm cuối cùng Trong bước này, ta xây dựng quan hệ giữa các nốt khái niệm Đầu tiên, cho mỗi cặp tham chiếu truy vấn và tham chiếu cá thể đã nhận diện, ta tìm một con đường giữa hai khái niệm tương ứng trong domain ontology cho trước Sau đó, ta kết hợp tất cả những con đường này lại với nhau để tạo thành đồ thị khái niệm cuối cùng
Ví dụ, trong câu truy vấn (Q1), có một tham chiếu truy vấn của lớp Location
và một tham chiếu cá thể của lớp Company được nhận diện Con đường tương ứng
giữa chúng trong ontology cho trước được biểu diễn trong hình 3.4 và cũng là đồ thị khái niệm cuối cùng cho câu truy vấn
Company: Microsoft Location: ?
locatedIn
Figure 9 Hình 3.4 Xây dựng đường đi giữa hai lớp
Trang 31Trong câu truy vấn (Q2), có một tham chiếu truy vấn của lớp Person và hai tham chiếu cá thể của lớp JobPosition và Company Hình 2.9(a) cho thấy con đường giữa Person và JobPosition, và hình 2.9(b) cho thấy con đường giữa
JobPosition và Company Hình 3.5(c) là đồ thị khái niệm cuối cùng sau khi đã hợp
nhất hai con đường này
(a) Con đường giữa Person và JobPosition
(b) Con đường giữa JobPosition và Company
(c) Đồ thị khái niệm cuối cùng
Figure 10 Hình 3.5 Hợp nhất các đường đi
Trang 32Ta xét câu truy vấn tiếp theo:
(Q3) “What company does Bill Gates work for?”
Câu truy vấn này có một tham chiếu truy vấn thuộc lớp Company và một tham chiếu cá thể thuộc lớp Person Hình 3.6 cho thấy con đường giữa chúng trong
domain ontology, và đồ thị khái niệm truy vấn tương ứng Chú ý rằng trong con đường được tìm thấy thì một khái niệm JobPosition – được gán kiểu tham chiếu phát sinh – được tạo ra và thêm vào
3.2.2.3 Giải quyết nhập nhằng
Khi xử lí các câu truy vấn bằng ngôn ngữ tự nhiên để nhận dạng các khái niệm và cá thể như đã đề cập ở phần 3.2.2.1, đôi khi chúng ta gặp khó khăn trong việc xác định chính xác các khái niệm và cá thể có cùng một từ khóa, thậm chí khi
đã sử dụng từ vựng của ontology Phần này đề cập đến vài chiến thuật để giải quyết
sự không chắc chắn đó
Nhiều cá thể thuộc về cùng một khái niệm
Khi đưa ra câu truy vấn, người dùng có thể muốn tìm thông tin liên quan đến nhiều cá thể của cùng một khái niệm Trong trường hợp này, ta đơn giản tạo một nốt duy nhất cho tất cả các cá thể Ví dụ:
(Q4): “List all the persons who are CEO and Manager”
Person: Bill Gates
hasPosition withinOrganization
Company: ? JobPosition: *
Figure 11 Hình 3.6 Thêm vào tham chiếu phát sinh để hình thành đường đi
Trang 33Trong câu truy vấn này có hai cá thể CEO và Manager của cùng một khái niệm
JobPosition Hình 3.7 cho thấy đồ thị khái niệm cuối cùng
Nhiều khái niệm trên cùng một từ khóa/cụm từ:
Một từ khóa hoặc cụm từ nào đó trong câu truy vấn có thể được nhận dạng chỉ đến nhiều khái niệm khác nhau của ontology Giải pháp cho vấn đề này là xem xét tất các các đồ thị khái niệm truy vấn được tạo ra, vì tất cả chúng có thể đưa ra câu trả lời cho câu hỏi từ người sử dụng Ví dụ:
(Q5): Where is Tokyo?
Từ Tokyo có thể được nhận dạng thành hai khái niệm Capital và Company
Cho nên, sẽ có hai đồ thị khái niệm được tạo ra như trong hình 3.8 Đương nhiên, kết quả thu được khi xử lí các câu query nên nhắm đến yêu cầu của người sử dụng
JobPosition: Manager, CEO Person: ?
hasPosition
Figure 12 Hình 3.7 Một khái niệm có hai cá thể
Trang 34 Nhiều đường đi cho cùng một cặp tham chiếu truy vấn/cá thể:
Khi tìm đường đi giữa các khái niệm trong domain ontology tương ứng với các tham chiếu truy vấn/cá thể được nhận dạng trong câu truy vấn bằng ngôn ngữ tự nhiên, ta có thể gặp nhiều hơn một đường đi khả dĩ Trong các trường hợp như thế, chúng ta sẽ chọn con đường có các nốt quan hệ gần giống nhất với các từ khóa trong câu truy vấn Mức độ tương tự giữa các nốt truy vấn và các từ khóa cũng được định nghĩa trong bộ từ điển ontology khi xây dựng các quan hệ trong domain ontology Ví dụ:
(Q6): “Who is the creator of Google?”
Trong câu truy vấn này có một tham chiếu truy vấn Person, và một tham chiếu
cá thể Google của khái niệm Company Trong ontology có hai con đường khả dĩ giữa hai khái niệm Person và Company như được mô tả trong hình 3.9(a) và 3.9(b)
Location: ? Company: Tokyo
locatedIn
hasCapital
Figure 13 Hình 3.8 Nhiều khái niệm trên cùng một từ
Trang 35Tuy vậy, từ creator trong câu truy vấn có tương quan đến từ vựng ontology đã được định nghĩa cho quan hệ hasCreator Cho nên, con đường đầu tiên – hình 3.9(a) – sẽ
được ưu tiên và được chọn lựa là đồ thị khái niệm truy vấn cho câu truy vấn đã cho
3.3 Chuyển đổi đồ thị khái niệm thành câu truy vấn SeRQL
Để sử dụng đồ thị khái niệm cho việc truy vấn trên một cơ sở tri thức như KIM, ta cần tìm hiểu cơ chế quản lí và truy vấn của nó Sau đây ta sẽ lần lượt giới thiệu Sesame – công nghệ cho việc lưu trữ và xử lí tri thức được KIM sử dụng, SeRQL - ngôn ngữ truy vấn của Sesame, và sau cùng là giải thuật chuyển đổi đồ thị khái niệm thành SeRQL để áp dụng lên Sesame Phần này dựa trên bài báo của TS Cao Hoàng Trụ và các cộng sự[12]
3.3.1 Sesame
Để khai thác và quản lí tri thức được biểu diễn dưới dạng RDF và RDFS một cách hiệu quả đòi hỏi phải có một hệ thống lưu trữ và truy vấn một số lượng lớn các
Company: Google Person: ?
hasCreator
Person: ?
hasPosition withinOrganization
Company: Google JobPosition: *
(a) Con đường thứ nhất
(b) Con đường thứ hai
Figure 14 Hình 3.9 Nhiều đường đi cho một cặp khái niệm/cá thể