NGHIÊN CỨU CÁC PHƯƠNG PHÁP TIẾN HOÁ ONTOLOGY VÀ ỨNG DỤNG XÂY DỰNG ONTOLOGY PROFILE CÁ NHÂN

Nội dung chính của tiểu luận là nghiên cứu các phương pháp tiến hoá ontology.Qua đây cũng đề xuất công cụ hỗ trợ sự phát triển một hệ thống tiến hoá ontologytrong khung ứng dụng KAON, kh

ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN

BÀI THU HOẠCH BIỂU DIỄN TRI THỨC VÀ ỨNG DỤNG

Đề tài:

NGHIÊN CỨU CÁC PHƯƠNG PHÁP TIẾN HOÁ ONTOLOGY VÀ ỨNG DỤNG XÂY DỰNG

ONTOLOGY PROFILE CÁ NHÂN

Giảng viên hướng dẫn: PGS TS Đỗ Văn Nhơn Học viên thực hiện: Phạm Ngọc Giàu

Mã số học viên: CH1101080

TP Hồ Chí Minh - 2013

Lời cảm ơn

Em xin gửi lòng biết ơn sâu sắc đến Thầy PGS TS Đỗ Văn Nhơn đã tận tình hướng dẫn, truyền đạt cho em những kiến thức quí báu, cũng như hướng chúng em nghiên cứu nguồn kiến thức mới, khơi nguồn cho em thực hiện đề tài này

Em xin cảm ơn các Thầy Cô ở phòng Đào tạo sau đại học, Trường Đại học Côngnghệ thông tin, đã hỗ trợ tạo điều kiện thuận lợi cho em trong quá trình học tập cũng như quá trình thực hiện đề tài này

Em cũng xin cảm ơn các anh chị, các bạn học viên cùng lớp đã trao đổi, thảo luận đề tài này

Mặc dù, em đã nỗ lực hết sức để hoàn thành đề tài của mình nhưng dù sao những sai sót trong đề tài là điều không thể tránh khỏi, kính mong nhận được sự góp

MỤC LỤC

Lời cảm ơn i

Lời mở đầu iii

Chương 1: GIỚI THIỆU ONTOLOGY 1

1.1 Tìm hiểu ontology 1

1.2 Ngôn ngữ ontology 4

1.2.1 RDFS(RDF_Schema) 4

1.2.2 OWL(Web Ontology Language) 5

1.3 Công cụ hỗ trợ xây dựng và quản trị ontology 5

Chương 2: CÁC PHƯƠNG PHÁP TIẾN HOÁ ONTOLOGY 6

2.1 Giới thiệu 6

2.2.Cơ sở của sự tiến hoá ontology 7

2.3.Quá trình tiến hoá ontology 9

2.4.Các phương pháp tiến hoá ontology 1 1 2.4.1 Phương pháp tiếp cận thủ tục với ngữ nghĩa thay đổi 12

2.4.2 Phương pháp tiếp cận khai báo với ngữ nghĩa thay đổi 25

2.5.Tiến hoá ontology trong KAON 35

2.5.1 KAON 35

2.5.2 Tiến hóa ontology trong KAON API 36

2.5.3 Tiến hóa ontology trong các ứng dụng KAON 37

Chương 3: FCA VÀ TIẾN HOÁ ONTOLOGY TỰ ĐỘNG 39

3.1.Tìm hiểu về FCA (Formal Concepts Analysis) 39

3.2.Ứng dụng FCA trong tự động hoá tiến hoá ontology 46

Chương 4: ỨNG DỤNG XÂY DỰNG ONTOLOGY PROFILE CÁ NHÂN DÙNG CÔNG CỤ PROTÉGÉ 51

4.1 Công cụ Protégé 5 1 4.2 Các bước xây dựng Ontology bằng Protégé 5 1 4.3 Xây dựng ontology cho profile cá nhân dùng Protégé 5 2 KẾT LUẬN 57

TÀI LIỆU THAM KHẢO 58

Trang ii

Lời mở đầu

Ontology được xem là một dạng biểu diễn tri thức lý tưởng cho các ứng dụngtruy hồi thông tin Tuy nhiên, để áp dụng được trong các ứng dụng có tính thực tế,các ontology được xây dựng sơ bộ trong các phòng thí nghiệm cần được bổ sung rấtnhiều kiến thức thực tế, hoặc thậm chí có những thay đổi mang tính cấu trúc của hệthống ontology Trong nghiên cứu hiện nay, quá trình thay đổi này được gọi là sự

tiến hoá ontology.

Các phương pháp tiến hoá ontology được công bố hiện nay còn dựa nhiều vàocác kỹ thuật thủ công do con người tiến hành, khiến cho quá trình tiến hoá trở nênkhông thuận tiện và mất rất nhiều công sức cũng như thời gian Do đó, một phươngpháp thực hiện việc tiến hoá ontology tự động nhưng phải có độ chính xác chấp nhậnđược là rất cần thiết

Các nghiên cứu trước đây đã đưa ra một hướng tiếp cận sinh tự động ontology,

dựa trên lý thuyết Phân tích khái niệm hình thức (Formal Concept Analysis - FCA).

Trong hướng tiếp cận này, ontology được định nghĩa một cách hình thức như một môhình toán học sử dụng các định nghĩa về khái niệm của FCA để biểu diễn tri thức.Ontology cũng có thể biểu diễn các khái niệm không chắc chắn nếu cần thiết Nghiêncứu này cung cấp một cơ sở lý thuyết nền tảng vững chắc để tiếp tục phát triển lýthuyết về tiến hoá ontology

Nội dung chính của tiểu luận là nghiên cứu các phương pháp tiến hoá ontology.Qua đây cũng đề xuất công cụ hỗ trợ sự phát triển một hệ thống tiến hoá ontologytrong khung ứng dụng KAON, không chỉ cho phép tự động hoá quá trình tiến hoáontology, mà còn giúp các nhà thiết kế ontology thực hiện các yêu cầu phù hợp nhất,cũng như đưa ra các đề xuất hợp lý hơn để các ontology liên tục được cải thiện trên

cơ sở của lý thuyết Về cấu trúc tiểu luận gồm bốn chương :

Chương 1: Tìm hiểu về khái niệm ontology, các ngôn ngữ ontology, các công cụ hỗ

trợ xây dựng và quản trị ontology, cũng như các phương thức xây dựng ontology

Chương 2: Tìm hiểu về cơ sở của sự tiến hoá ontology, quá trình tiến hoá ontology,

trình bày các phương pháp tiến hoá ontology và công cụ hỗ trợ sự tiến hoá ontologytrong khung ứng dụng KAON

Chương 3: Tìm hiểu về FCA và các ứng dụng FCA trong tự động hoá tiến hoá

ontology

Chương 4 : Ứng dụng xây dựng Ontology cho Profile cá nhân dùng công cụ Protégé.

Trang iii

Báo cáo Biểu diễn tri thức và ứng dụng GVHD: PGS TS Đỗ Văn Nhơn

Chương 1 GIỚI THIỆU ONTOLOGY

1.1 Tìm hiểu ontology

Cơ bản về sự phân loại

Khi người ta đưa ngữ nghĩa vào Web nghĩa là xác định ngữ nghĩa cho các tàinguyên trên Web, và phải xác định các tài nguyên đó thuộc lớp nào, Cho nên, cần

có một cơ chế tự động để máy tính có thể phân loại được các tài nguyên này

Có hai phương pháp phân loại là hình thức và không hình thức Cách phân

loại không hình thức có thể không cần sự chính xác Ví dụ, có thể nói thành phốSài gòn hay thành phố Hồ Chí Minh đều như nhau Cách phân loại hình thức thìcần sự chính xác Ví dụ trong các ngành khoa học, y tế, …

Các hệ thống phân loại theo kiểu hình thức được chia làm hai dạng Đó là phân

loại phân cấp và phân loại phân nhóm Phân loại phân cấp dựa trên cấu trúc phân cấp như: danh sách phân cấp hoặc cây phân cấp Trong khi phân loại phân

nhóm dựa trên phân mục Hiện nay, cả hai hình thức trên đều được sử dụng tronglĩnh vực Web ngữ nghĩa để phân loại các tài nguyên

+ Chùa Thiên Mụ

Tuy nhiên tương tự danh sách phân cấp, cấu trúc cây phân cấp cũng không thểhiện được các quan hệ phức tạp thường thấy trong thế giới thực Trong thực tế, một sựvật không chỉ thể hiện tính chất của một mà là nhiều sự vật khác Có nghĩa là một núttrong cây phân cấp có thể có nhiều nút cha Ví dụ đối tượng “con ếch” có thể sẽ phảivừa thuộc lớp “động vật sống dưới nước” vừa thuộc lớp “động vật sống trên cạn”

Điều này đã dẫn tới sự ra đời của một cấu trúc phân loại phức tạp hơn là Cyc

Ontology

Cyc Ontology là cấu trúc tương tự cây phân cấp nhưng mỗi nút trong nó có thể có

nhiều cha (tương ứng việc một sự vật có thể phân loại vào nhiều nhóm) Đây là cấutrúc đủ phức tạp để mô tả tri thức thế giới thực cũng như phục vụ cho việc suy luậntrên dữ liệu Web ngữ nghĩa Hình bên dưới là một ví dụ về Cyc Ontology

1.1.1 Ontology

Trong ngành khoa học máy tính, Ontology là sự đặc tả rõ ràng, hình thức củamột tập hợp các khái niệm được chia sẻ thuộc một lĩnh vực quan tâm và quan hệgiữa các khái niệm này Nói cụ thể hơn, ontology cung cấp bộ từ vựng chung baogồm các khái niệm, các thuộc tính quan trọng, các định nghĩa về các khái niệm vàcác thuộc tính này Ngoài bộ từ vựng, ontology còn cung cấp các ràng buộc của bộ

từ vựng Bộ từ vựng này được định nghĩa trong một lĩnh vực chuyên môn nào đó

Sự định nghĩa này có thể được hiểu bởi cả con người lẫn máy tính Một ontologybao gồm các thành phần sau:

tượng có thể bao gồm: người, thú, xe, nguyên tử, hành tinh, trang web, Nói đúng ra,ontology không cần chứa bất kỳ đối tượng nào, nhưng ontology có thể cung cấp mộtphương tiện để phân loại các đối tượng

Lớp (khái niệm): Class Hầu hết ontology đều tập trung xây dựng các lớp được tổ

chức theo cấu trúc phân cấp để mô tả các lớp trong miền cần quan tâm Ví dụ “động

vật” là một lớp trong ngữ cảnh động vật học Bên dưới lớp này có thể có các lớp con

ví dụ “động vật có vú” và “động vật không có vú”…

qua việc khai báo các thuộc tính của chúng Mỗi một thuộc tính đều có tên vàgiá trị của thuộc tính đó Các thuộc tính được sử dụng để lưu trữ các thông tin

mà đối tượng có thể có Ví dụ, đối tượng là con người thì có thể có các thuộctính: Họ_tên, ngày_sinh, quê_quán, …

hệ với lớp khác như thế nào Ví dụ trong ontology chứa lớp XEHAIBANH và lớp XE

có thể được kết nối nhau bởi một quan hệ ‘là lớp con của’ hay ‘is-a-subclass-of’ Có

thể phát biểu quan hệ trên như sau: XEHAIBÁNH là một lớp con của lớp XE.

Các đối tượng, lớp, thuộc tính và quan hệ được sử dụng để xây dựng cácontology đơn giản Còn ontology phức tạp thì được bổ sung thêm hàm(function) và các tiên đề (axioms) từ ontology đơn giản

1.1.2 Ontology trong Web ngữ nghĩa

Web ngữ nghĩa là thế hệ tiếp theo của Web truyền thống WWW Nó là nềntảng cho ontology để nâng cao nội dung ngữ nghĩa hình thức Biểu diễn ngữ nghĩacủa nguồn tài nguyên trên web là công việc chính của Web ngữ nghĩa Để thựchiện điều này, kiến trúc các lớp của Web ngữ nghĩa là cần thiết Các lớp này cócông dụng như sau:

Lớp XML miêu tả cấu trúc dữ liệu.

Lớp RDF miêu tả ngữ nghĩa dữ liệu.

Lớp Ontology miêu tả mối quan hệ phổ

biến hình thức về ngữ nghĩa dữ liệu

Lớp Logic cho phép suy luận thông minh

với các dữ liệu có ý nghĩa

Lớp Proof đưa ra các luật để suy luận

Lớp Trust đảm bảo tính tin cậy của các ứng dụng trên Web ngữ nghĩa.

1.1.3 Vai trò của ontology

Với ý nghĩa và cấu trúc như trên, ontology trở thành một công cụ quan trọngtrong lĩnh vực Web ngữ nghĩa Có thể kể ra một số lợi ích của ontology như:

 Chia sẻ những hiểu biết chung về các khái niệm

 Cho phép tái sử dụng tri thức

 Đặc tả rõ ràng về miền tri thức

 Cho phép tri thức độc lập với ngôn ngữ

 Cho phép tri thức trở nên nhất quán và tường minh

 Cung cấp một phương tiện cho công việc mô hình hoá

 Cung cấp một phương tiện cho việc suy luận

1.1.4 Xây dựng ontology

Có nhiều phương pháp khác nhau để xây dựng một ontology, nhưng nhìn

chung các phương pháp đều thực hiện hai bước cơ bản là: xây dựng cấu trúc

lớp phân cấp và định nghĩa các thuộc tính cho lớp

Bên cạnh đó, công việc xây dựng ontology cũng cần phải tính đến khả năng mởrộng miền quan tâm trong tương lai, khả năng kế thừa các hệ thống ontology cósẵn, cũng như tính linh động để ontology có khả năng mô tả tốt nhất các quan hệphức tạp trong thế giới thực Các công đoạn cơ bản để xây dựng ontology:

Bước 1: Xác định miền quan tâm và phạm vi của ontology

Bước 2: Xem xét việc kế thừa các ontology có sẵn

Bước 3: Liệt kê các thuật ngữ quan trọng trong ontology

Bước 4: Xây dựng các lớp và cấu trúc lớp phân cấp

Bước 5: Định nghĩa các thuộc tính và quan hệ cho lớp

Bước 6: Định nghĩa các ràng buộc về thuộc tính và quan hệ của lớp

Bước 7: Tạo các thực thể cho lớp

1.2 Ngôn ngữ ontology

1.2.1 RDFS (RDF-Schema)

RDFS hay RDF-Schema, là một ngôn ngữ ontology cơ bản Nó được phát triển ở tầng trên của RDF cho nên bản thân RDF-Schema cũng chính là RDF, nó được mở rộng từ RDF và bổ sung thêm các tập từ vựng để hỗ trợ cho việc xây dựng các ontology được dễ dàng Như chúng ta đã biết, ngôn ngữ RDF chỉ giúp cho thông tin được thể hiện ở dạng bộ ba theo đúng mô hình RDF chứ thông tin vẫn chưa thể hiện gì về mặt ngữ nghĩa

Bởi vậy, xây dựng RDFS là điều cần thiết để hình thành nên ngữ nghĩa của thông tin, là cơ sở để xây dựng các công cụ tìm kiếm ngữ nghĩa RDFS và RDF có mối liên hệ tương đối gần gũi nên đôi lúc ta gọi ngôn ngữ này là

RDF/RDFS

Hình 1.5 cho chúng ta sự phân biệt giữa RDFS với RDF :

Trong hình vẽ chúng ta thấy, ở tầng RDF chỉ biểu diễn được thông tin ởdạng bộ ba Đến tầng RDFS, thông tin đã được phân loại rõ ràng Chẳng hạnnhư David Billington có kiểu là associate professor và associate professor làlớp con của Academic Staff member , …

1.2.2 OWL (Web Ontology Language)

OWL là ngôn ngữ ontology khá mạnh, nó ra đời sau RDFS nên biết kếthừa những lợi thế của ngôn ngữ này đồng thời bổ sung thêm nhiều yếu tố giúpkhắc phục được những hạn chế của RDFS OWL giúp tăng thêm yếu tố logiccho thông tin và khả năng phân loại, ràng buộc kiểu

OWL có nhiều ưu điểm hơn trong việc xây dựng hệ thống ontology thôngminh và có phân loại tốt Với những đặc điểm đó, OWL ngày nay đã trở thànhngôn ngữ ontology chính thức cho việc xây dựng và phát triển các hệ thốngWeb ngữ nghĩa

1.3 Công cụ hỗ trợ xây dựng và quản trị ontology

Về mặt lý thuyết, người xây dựng và quản trị ontology có thể không cần cáccông cụ hỗ trợ, thay vào đó có thể thực hiện trực tiếp bằng các ngôn ngữ Tuynhiên, cách này sẽ không khả thi khi ontology có kích thước lớn và cấu trúcphức tạp Thêm vào đó, việc xây dựng và quản trị ontology không chỉ đòi hỏiviệc tạo cấu trúc lớp phân cấp, định nghĩa các thuộc tính, ràng buộc , mà cònbao hàm việc giải quyết các bài toán liên quan trên nó Có rất nhiều bài toánliên quan đến một hệ thống ontology như:

 Trộn hai hay nhiều ontology

 Chuẩn đoán và phát hiện lỗi

 Ánh xạ qua lại giữa các ontology

 Suy luận trên ontology

Những khó khăn trên đã khiến các công cụ trở thành một thành phần không thểthiếu, quyết định đến chất lượng của một hệ thống ontology Hiện có rất nhiềucông cụ có khả năng hỗ trợ người thiết kế giải quyết những bài toán liên quan

Có thể kể ra một số như: Sesame, Protégé, Ontolingua, Chimaera, OntoEdit,OidEd

Chương 2 CÁC PHƯƠNG PHÁP TIẾN HOÁ ONTOLOGY

2.1 Giới thiệu

2.1.1 Định nghĩa

Thuật ngữ tiến hoá ontology được định nghĩa như sau:

Định nghĩa 2.1 “Tiến hoá ontology là sự thích ứng kịp thời của ontology với

những thay đổi phát sinh và tầm ảnh hưởng nhất quán của những thay đổi này đốivới các kết quả phụ thuộc”

Từ một ontology liên tục được thay đổi, dẫn đến sự cần thiết của quá trình tiến hoáontology là điều không thể tránh khỏi Nhiệm vụ của tiến hoá ontology là làm rõmột cách hình thức tất cả các yêu cầu thay đổi đến từ các nguồn khác nhau (ví dụngười sử dụng, các quy trình nội bộ, môi trường thương mại), được thực hiện trênontology và trên các ứng dụng phụ thuộc trong khi vẫn giữ tính nhất quán củachúng

Ví dụ: Hình 2.1 minh hoạ vai trò của sự tiến hoá ontology trong một hệ thốngthương mại

2.1.2 Tầm quan trọng của sự tiến hoá ontology

 Ontology được phát triển và là một quá trình năng động với một ontologythô ban đầu, nó được xem xét, tinh chế và bổ sung các chi tiết Hơn nữa, cácontology được sử dụng và trong thời gian sử dụng của nó, tri thức dựa trên

đó sẽ thay đổi và phát triển Một ontology sẽ nhanh chóng trở thành lỗi thờinên phải được thay đổi và thích ứng với những thay đổi của môi trường, nhucầu người dùng, v v Do đó, sự tiến hoá ontology là điều cần thiết, nó sẽthích ứng được với những thay đổi xảy ra

 Sự tiến hoá ontology hiện nay là rất quan trọng Lý do chính yếu của sự tiếnhoá là do sự gia tăng số lượng các ontology sử dụng và các chi phí gia tăng,kết hợp với sự thích ứng của chúng theo các yêu cầu thay đổi

2.2 Cơ sở của sự tiến hoá ontology

2.2.1 Ontology KAON

Theo Ontology KAON, mọi thông tin được tổ chức theo mô hình OI-models(Ontology-Instance models), có chứa các thực thể ontology sau: khái niệm, thuộctính và thể hiện

Ví dụ về ontology, được thể hiện trong Hình 2.2

Mô hình ontology miền đại học Nó chứa tập các khái niệm như

“Professor”, “Student”, “Project”, và một tập các thuộc tính giữa chúng (ví dụnhư “hasFirstName”, “includes”, v v.) Lưu ý rằng các khái niệm được hiểu làtập của các thực thể trong khi các thuộc tính thiết lập các quan hệ giữa các thựcthể này Mỗi thuộc tính có thể có các khái niệm miền cũng như các khái niệmvùng Ví dụ, khái niệm miền cho thuộc tính “includes” là khái niệm “Project”

trong khi khái niệm vùng là khái niệm “Person” Cả thuộc tính miền lẫn thuộctính vùng đều ràng buộc bởi các kiểu thể hiện Lưu ý, một thuộc tính có thể tồntại mà không bị gắn liền với một khái niệm nào.

Hình 2.3 cho thấy sự mở rộng của ontology trong Hình 2.2 với một nhóm thểhiện

Ontology mở rộng được xây dựng bằng cách xác định các thể hiện, chúngđược tạo ra từ các khái niệm, và thiếc lập thuộc tính giữa các thể hiện Thuộctính phải thực hiện theo các ràng buộc miền và vùng Ví dụ, “SteffenWezler” làmột thể hiện của khái niệm “BSc Student”, “OntoLogging” là một thể hiện củakhái niệm “Project”, và có một thuộc tính liên quan đến hai thể hiện thông quathuộc tính “includes”

Các ontology KAON được xây dựng hoặc mở rộng trên các ontologykhác, tạo thành một đồ thị của các ontology phụ thuộc

Hình 2.4 cho thấy đồ thị ontology PO sử dụng lại đồ thị ontology BO Các kháiniệm “Research Project” và “Industrial Project”, được thêm vào trong ontologyPO

2.2.2 Mô hình đồng nhất ontology

Tính đồng nhất là mức độ của sự đồng dạng, sự chuẩn hoá, và không mâuthuẫn giữa các bộ phận của một hệ thống Từ quan điểm logic, tính nhất quán làmột thuộc tính của một hệ thống (logic), mà các sự kiện có thể suy luận từ một

mô hình này thì không được mâu thuẫn với mô hình khác

2.2.3 Thay đổi ontology

Có hai vấn đề lớn liên quan đến sự tiến hoá ontology Vấn đề đầu tiên là tìmhiểu ontology thay đổi như thế nào khi sự tiến hoá ontology được thực hiện.Vấn đề thứ hai liên quan đến việc quyết định khi nào và làm sao để sửa đổi mộtontology nhưng vẫn giữ tính nhất quán của nó

Việc áp dụng một thay đổi ontology không phải lúc nào cũng cho phépontology ở trong một trạng thái nhất quán Ví dụ như Hình 2.5, việc tạo kháiniệm “PhD Student” là một khái niệm cha của khái niệm “Person” sẽ gây ratính không nhất quán

Định nghĩa 2.2 Cho một ontology O với yêu cầu thay đổi Ch, việc áp dụng

thay đổi Ch cho ontology O dẫn đến một ontology O’:

O’ = Ch o O = Ch(O)Trong đó ° là một toán tử thực hiện việc áp dụng thay đổi Ch trên ontology O

Lưu ý, thay đổi Ch có thể được áp dụng nếu và chỉ nếu các ontology O đáp ứngcác tiền điều kiện của sự thay đổi và tồn tại ít nhất một ontology O’ đáp ứngđược tập các hậu điều kiện của sự thay đổi này

2.3 Quá trình tiến hoá ontology

Quá trình tiến hoá gồm sáu giai đoạn: (1) thu thập thay đổi (capturing), (2) miêu tảthay đổi (representation), (3) ngữ nghĩa thay đổi (semantic), (4) tầm ảnh hưởngthay đổi (propagation), (5) thực hiện thay đổi (implementation), và (6) tính hợp lệthay đổi (validation)

 Giai đoạn thu thập thay đổi (Change Capturing)

Đây là giai đoạn phát hiện sự thay đổi ontology (Hình 2.7) Chúng ta phân biệt hailoại thay đổi: thay đổi từ trên xuống và thay đổi từ dưới lên Nói chung, hai thayđổi này là nhiệm vụ của giai đoạn thu thập thay đổi

Lưu ý, hai loại thay đổi này tương ứng với hai phương pháp Các thay đổi từ trênxuống (tính suy diễn) dùng kỹ thuật suy diễn tri thức trực tiếp từ các chuyên gia(các chuyên gia miền hay người dùng cuối) Mặt khác, các thay đổi từ dưới lên(tính quy nạp) phù hợp với kỹ thuật máy học Loại thay đổi từ dưới lên là cấu trúcchính của ontology(Hình 2.8)

Yêu cầu về chức năng (Functional Requirement)

Yêu cầu về chức năng (Hình 2.7) sau khi được áp dụng sẽ giải quyết các thay đổi củaontology trong trạng thái nhất quán Yêu cầu này bao gồm hai khía cạnh quan trọngcủa sự tiến hoá ontology:

Yêu cầu về chức năng có thể được thực hiện thông qua bốn giai đoạn thể hiện trongHình 2.9 Đây là các giai đoạn cốt lõi hình thành quá trình tiến hoá ontology từ khichúng thực hiện yêu cầu bắt buộc (tức yêu cầu về chức năng)

 Giai đoạn miêu tả thay đổi (representation): Khi yêu cầu

thay đổi ontology được đưa vào, giai đoạn này miêu tả các thay đổi một cách hìnhthức và rõ ràng (H 2.9)

 Giai đoạn ngữ nghĩa thay đổi (semantic): Khi yêu cầu thay

đổi ontology được chấp nhận thì giai đoạn này sẽ ngăn chặn tính không nhất quánxảy ra

 Giai đoạn tầm ảnh hưởng thay đổi (propagation): Giai

đoạn này tiếp nhận các yêu cầu thay đổi từ giai đoạn ngữ nghĩa thay đổi, nó sẽ thực

hiện việc tính toán các thay đổi bổ sung để đảm bảo sự chuyển tiếp của ontologyvào một trạng thái nhất quán

 Giai đoạn thực hiện thay đổi (implementation): Giai đoạn

này sẽ thực hiện các thay đổi cho tất cả các kết quả phụ thuộc (như các thể hiệnphân tán, các ontology phụ thuộc và các ứng dụng phụ thuộc) Các thay đổi này sẽ

cập nhật lại cho ontology ban đầu Yêu cầu về điều khiển (Guidance

Requirement)

Đây cũng chính là giai đoạn tính hợp lệ thay đổi

 Giai đoạn tính hợp lệ thay đổi (validation): Giai đoạn này

giúp các nhà thiết kế ontology tìm hiểu xem họ đã xây dựng ontology đúng haychưa Nó đòi hỏi cách xử lý, bởi vì nếu không có cách xử lý thích hợp, chúng takhông thể đánh giá cách xử lý thỏa đáng trong thời gian chạy

Yêu cầu cải tiến (Refinement Requirement): Yêu cầu cải tiến ontology cho phép

nó được cải thiện liên tục (Hình 2.7) Các mô hình cải tiến nhằm phục vụ trực tiếp chocác nhà thiết kế ontology Yêu cầu cải tiến muốn thực hiện được phải thông qua giaiđoạn thu thập thay đổi (change capturing) của quá trình tiến hoá ontology

2.4 Các phương pháp tiến hoá ontology

Ngữ nghĩa thay đổi là một giai đoạn trong quá trình tiến hoá ontology cho phépgiải quyết các thay đổi ontology một cách có hệ thống nhưng vẫn bảo đảm tính nhấtquán của toàn bộ ontology Phần này đưa ra cái nhìn tổng quan về các vấn đề xảy ratrong giai đoạn ngữ nghĩa thay đổi và đưa ra hai phương pháp chính để giải quyếtnhưng vẫn đảm bảo tính nhất quán:

 Phương pháp tiếp cận thủ tục với ngữ nghĩa thay đổi.

 Phương pháp tiếp cận khai báo với ngữ nghĩa thay đổi.

2.4.1 Phương pháp tiếp cận thủ tục với ngữ nghĩa thay đổi

2.4.1.1 Phân tích ví dụ

Vai trò thiết yếu của giai đoạn ngữ nghĩa thay đổi trong quá trình tiếnhoá ontology là để tìm ra những thay đổi cơ bản Ví dụ, khi một khái niệmtrong hệ thống phân cấp được xóa bỏ, thì tất cả các mối quan hệ subconcepts

có thể hoặc bị xóa hoặc kết nối lại với các khái niệm khác

Trong Hình 2.10 ta thấy nhận thấy có nhiều cách khác nhau để giải quyếtyêu cầu cho việc loại bỏ khái niệm “Student” Giải pháp đầu tiên (Hình 2.10b)không chứa bất kỳ mối quan hệ subconcepts của khái niệm “Student” Giảipháp thứ hai (xem Hình 2.10c) tất cả các mối quan hệ subconcepts của kháiniệm “Student” được giữ lại và kết nối với khái niệm cha “Person” Giải phápcuối cùng (xem Hình 2.10c) là bảo tồn tất cả các mối quan hệ subconcepts khikết nối chúng vào thư mục gốc của hệ thống phân cấp khái niệm.

Mỗi giải pháp này phù hợp với một số tình huống Ví dụ, giải pháp đầutiên rất hữu ích để giữ một ontology càng tối thiểu càng tốt Giải pháp thứ haiphù hợp hơn cho việc bảo tồn các thực thể càng nhiều càng tốt Giải pháp cuốicùng chỉ giữ lại các thông tin về mối quan hệ subconcepts, có thể thông báocho nhà thiết kế ontology về những quyết định trước đó

Chúng ta thấy rằng đối với một số thay đổi ontology, nó có thể sinh ratập các thay đổi bổ sung khác, dẫn đến trạng thái nhất quán cuối cùng củaontology cũng khác nhau Như vậy, vai trò của giai đoạn ngữ nghĩa thay đổiđối với hệ thống tiến hoá ontology giúp cho các nhà thiết kế ontology giảiquyết mọi ảnh hưởng phụ của các thay đổi để hoàn thành sự thay đổi mà họnêu ra Họ có thể đưa ra giải pháp thích hợp cho một yêu cầu muốn thực hiện,

và có khả năng định hướng quá trình này Để làm được như vậy, nhà thiết kếontology phải đưa ra chiến lược tiến hoá (xem 4.1.3), cho phép tùy chỉnh quá

trình phát sinh của các thay đổi bổ sung theo nhu cầu của họ Theo cách đó,nhà thiết kế ontology có thể chuyển đổi một ontology với trạng thái nhất quánmong muốn.

2.4.1.2 Mô tả phương pháp tiếp cận thủ tục

Phương pháp tiếp cận thủ tục được minh họa trong Hình 2.11 Nhà thiết kếontology tạo một yêu cầu thay đổi Yêu cầu này được hình thành trong giaiđoạn miêu tả thay đổi (Hình 2.9) của quá trình tiến hoá ontology và nó baogồm một hoặc nhiều thay đổi được hỗ trợ bởi hệ thống tiến hoá ontology Mộtyêu cầu (Hình 2.11) được miêu tả như là một chuỗi các thay đổi ontology

Chuỗi này thông qua giai đoạn ngữ nghĩa thay đổi trong Hình 2.11 Vai tròcủa nó là:

 Ngăn ngừa những thay đổi không phù hợp có nghĩa là thay đổi đó sẽgây ra mâu thuẫn hay tính không nhất quán

 Đảm bảo tính nhất quán trong trường hợp yêu cầu được áp dụng.Chuỗi này được xử lý lần lượt, cho đến khi không còn thay đổi nào trongchuỗi các thay đổi

Sự ngăn cấm các thay đổi ontology không phù hợp được giải quyết bằng cáchkiểm tra tiền điều kiện Module phát sinh thay đổi có nhiệm vụ bảo tồn tínhnhất quán Để bảo tồn tính nhất quán, một chiến lược tiến hoá được áp dụng

có trách nhiệm định hướng làm thế nào để bảo tồn tính nhất quán Quá trìnhnày được lặp đi lặp lại cho đến khi tất cả các thay đổi được xử lý Cuối cùng,tất cả các thay đổi được xử lý sẽ áp dụng cho ontology Điều này được thựchiện bằng cách thông qua các hậu điều kiện của mỗi thay đổi

Ví dụ phương pháp tiếp cận thủ tục

Yêu cầu của người dùng cho việc loại bỏ mối quan hệ instanceOf giữathể hiện “SteffenWezler” và khái niệm “BSc Student” từ ontology được hiểnthị ở Hình 2.3, sẽ được xử lý theo cách sau: Đầu vào của giai đoạn ngữ nghĩa

thay đổi, tức là yêu cầu thay đổi RemoveInstanceOf(“SteffenWezler”, “BScStudent”) – nghĩa là xóa thể hiện SteffenWezler ra khỏi khái niệm BScStudent Các tiền điều kiện của việc loại bỏ được thực hiện Mặt khác, không

có khái niệm nào để đặc tả cho thể hiện “SteffenWezler”, thể hiện

“SteffenWezler” sẽ là một thể hiện mồ côi Do đó, module phát sinh thay đổi

sẽ tạo ra những thay đổi mới Cách giải quyết của thể hiện mồ côi

“SteffenWezler” có thể được thực hiện theo hai cách: bằng cách tạo ra thayđổi RemoveInstance(“SteffenWezler”) – xoá luôn thể hiện SteffenWezlerhoặc thay đổi AddInstanceOf (“SteffenWezler”, “Student”) – thêm thể hiệnSteffenWezler vào khái niệm Student Vì vậy, một chiến lược tiến hoá đưavào là rất cần thiết cho việc kiểm soát làm thế nào để xóa bỏ tính không nhấtquán xảy ra Trong module phát sinh thay đổi sẽ phát sinh một trong các thayđổi được đề xuất (ví dụ xóa thể hiện SteffenWezler ra khỏi khái niệm

“Student”) Phần phát sinh này phụ thuộc vào nhu cầu sửa đổi của nhà thiết kếontology Nhưng dù sao đi nữa, việc phát sinh thay đổi đã được xử lý theocách tương tự Quá trình này lặp lại cho các thay đổi được tạo ra, đến khi tất

cả các thay đổi trong danh sách các thay đổi được xử lý Nếu các thay đổiđược xử lý hết và ontology vẫn còn mâu thuẫn, thì toàn bộ quá trình tiến hoáđược hủy bỏ Ngược lại, quá trình này sẽ kết thúc bởi việc áp dụng liên tục tất

cả các thay đổi từ danh sách các thay đổi (tức là các thay đổi được yêu cầu vàcác thay đổi được tạo ra) cho ontology Điều này được thực hiện trong module

áp dụng thay đổi

2.4.1.3 Chiến lược tiến hoá

Các nhà thiết kế ontology mong muốn quản lý các thay đổi không ở trong mộttrạng thái nhất quán tùy ý, mà trong một trạng thái nhất quán được thực hiệnbởi một số ràng buộc Do đó, chiến lược tiến hoá được ra đời để phục vụ chomục đích của họ Chiến lược tiến hoá được phát triển như là một phương pháp

để “tìm” ontology nhất quán đáp ứng nhu cầu của nhà thiết kế ontology.Chiến lược tiến hoá cố gắng nắm bắt sự đa dạng của cách giải quyết sự tiếnhoá Tất cả các hệ thống tiến hoá ontology đang tồn tại áp dụng cách giảiquyết tiến hoá riêng của mình Phương pháp này đơn giản và bất tiện, vì nókhông cung cấp cho các nhà thiết kế ontology cách thích ứng của mộtontology để phù hợp với các ứng dụng riêng lẻ Vì vậy, chúng ta tiến mộtbước xa hơn bằng cách cung cấp một sự lựa chọn linh hoạt của toàn bộ chiếnlược liên quan đến sự thay đổi ontology

Để tạo ra các thay đổi bổ sung cho ontology, người ta đưa ra khái niệm đồ thịphụ thuộc Để nâng cao tính trừu tượng, người ta miêu tả đồ thị này như làmột ma trận thưa được hiển thị trong Bảng 2.1 Chúng ta gọi nó là ma trậnphụ thuộc

Các hàng và các cột của ma trận này là dấu hiệu các thay đổi ontology Nếumột phần tử của ma trận phụ thuộc có giá trị 0, có nghĩa là một thay đổi Chk

được gán với hàng k có thể chưa bao giờ gây ra một sự thay đổi Chj biểu thịcho cột j Mặt khác, một thay đổi Chk có thể tạo ra một sự thay đổi Chj khi cácđiều kiện được đáp ứng Các phần tử tương ứng của ma trận phụ thuộc chứacác điều kiện này Lưu ý rằng những thay đổi khác nhau (tức là Chj) có thể tạo

ra kết quả tương tự và kết quả này bám sát tính độc lập về mục đích của nó(tức là sự thay đổi ban đầu Chk)

Định nghĩa 2.3 Sự phát sinh thay đổi được định nghĩa là:

ChangeGeneration: CH  2CH,trong đó mỗi ChangeGeneration(ChK)={Chk1, ., Chki, ., Chkn}, được xácđịnh cho sự thay đổi cụ thể ChK, có thể được áp dụng

Để cho phép nhà thiết kế ontology thay đổi một ontology theo độ ưu tiên,chúng ta tìm hiểu một tập các khái niệm sau đây:

Định nghĩa 2.4 RP (Resolution Points) là một tập các điểm giải quyết,

RP={RPi / i=1, ,9} (xem Bảng 2.2), trong đó mỗi điểm giải quyết là một tìnhtrạng xử lý có thể xảy ra trong việc giải quyết thay đổi

Định nghĩa 2.5 Chiến lược tiến hoá cơ bản EES (Elementary Evolution

Strategy) là một tập các cách có thể xử lý điểm giải quyết, EES={EESj /j=1, ,23} (xem Bảng 2.2)

Định nghĩa 2.6 Cách giải quyết RW (Resolution Way) là một tập các chiến

lược tiến hoá cơ bản có thể xảy ra cho việc xử lý một điểm giải quyết cụ thể:

RW: RP  2EES

Ví dụ, trong trường hợp điểm giải quyết về việc xử lý các mối quan hệ subconceptscủa một khái niệm C, các tùy chọn (ví dụ như chiến lược tiến hoá cơ bản) có thể là:

 Các mối quan hệ subconcepts của C có thể bị xóa

 Các mối quan hệ subconcepts của C có thể được kết nối với các khái niệmcha của C

 Các mối quan hệ subconcepts của C có thể được kết nối với khái niệm gốccủa hệ thống phân cấp

Do đó, đối với điểm giải quyết RP1 có ba chiến lược tiến hoá cơ bản (EES1, EES2 vàEES3) được xác định: xoá, kết nối lại với khái niệm cha và kết nối lại với khái niệmgốc Chúng tạo thành ba cách giải quyết Sự tác động của các chiến lược tiến hoá cơbản này đối với ontology, cuối cùng được minh họa trong Hình 2.10 Tương tự nhưvậy, các chiến lược tiến hoá cơ bản cho tất cả các điểm giải quyết khác cũng có thểluận ra được

Các điểm giải quyết có thể xảy ra trong quá trình giải quyết thay đổi và tập các chiếnlược tiến hoá cơ bản liên quan đến mỗi điểm giải quyết được thể hiện trong Bảng 2.2.Một số điểm giải quyết có thể được đặc trưng cho một sự thay đổi cụ thể; một số trongchúng có thể được sử dụng trong thời gian giải quyết của nhiều thay đổi

Để làm rõ ý nghĩa của các điểm giải quyết và các chiến lược tiến hoá cơ bản củachúng, ở đây chúng ta sẽ tìm hiểu điểm giải quyết về RP3 chi tiết hơn Điểm giải quyếtnày được xem xét khi mối quan hệ subconcept giữa hai khái niệm cần xóa, như ví dụtrong Hình 2.12 Để giải quyết việc loại bỏ mối quan hệ subconcept giữa khái niệm

“Child” và khái niệm “Parent” bằng cách giả sử rằng khái niệm “Child” phải được bảotồn, có một yêu cầu cần phải giải quyết là làm gì với các thuộc tính được kế thừa thôngqua mối quan hệ subconcept này Tập các thuộc tính này bao gồm các thuộc tính miềncủa khái niệm “Parent” như là “pdC1”, …, “pdCn”, các thuộc tính vùng của khái niệm

“Parent” như “prC1”, …, “prCm”, cũng như các thuộc tính mà khái niệm “Parent” thừa

kế từ tất cả các khái niệm cha của nó (xem khái niệm “ParentOfParent” trong Hình2.12)

Báo cáo Biểu diễn tri thức và ứng dụng GVHD: PGS TS Đỗ Văn Nhơn

Bảng 2.1 Các mối quan hệ nhân quả (cause and effect) giữa các thay đổi ontology được tổ chức như là ma trận phụ

thuộc (Dependency matrix) Giá trị x của một phần tử, tức là Dependency[i] [j] = x, chỉ ra rằng việc giải quyết sựthay đổi liên quan tới các hàng i có thể gây ra sự thay đổi liên quan tới cột j

Báo cáo Biểu diễn tri thức và ứng dụng GVHD: PGS TS Đỗ Văn Nhơn

Báo cáo Biểu diễn tri thức và ứng dụng GVHD: PGS TS Đỗ Văn Nhơn

Bảng 2.2 Các điểm giải quyết và các chiến lược tiến hoá cơ bản của chúng

Có ba giải pháp được mô tả bởi các chiến lược tiến hoá cơ bản EES7, EES8 và EES9.Giải pháp đơn giản nhất để đạt được bằng sự lựa chọn của EES7 là không ảnh hưởngđến các thuộc tính của mối quan hệ superconcepts Chiến lược tiến hoá cơ bản EES8cho phép tất cả thuộc tính (bao gồm cả thuộc tính kế thừa) ảnh hưởng đến khái niệm

có cha thay đổi Với cách lựa chọn chiến lược tiến hoá cơ bản này, khái niệm “Child”

sẽ là khái niệm miền cho các thuộc tính “pdC1”, , “pdCn” thừa kế từ khái niệm

“Parent”, và khái niệm “Child” cũng sẽ là khái niệm miền cho các thuộc tính

“pdP1”, , “pdPk” thừa hưởng từ khái niệm “ParentOfParent” Tương tự, khái niệm

Báo cáo Biểu diễn tri thức và ứng dụng GVHD: PGS TS Đỗ Văn Nhơn

“Child” sẽ là khái niệm vùng cho các thuộc tính “prC1”, , “prCm” thừa kế từ kháiniệm “Parent” hoặc “Child” cũng sẽ là khái niệm vùng cho các thuộc tính “prP1”, ,

“prPl” thừa hưởng từ khái niệm “ParentOfParent” Giải pháp thứ ba được miêu tả bởichiến lược tiến hoá cơ bản EES9 chỉ ảnh hưởng các thuộc tính của khái niệm cha trựctiếp Bằng việc thông qua chiến lược tiến hoá cơ bản này, khái niệm “Child” chỉ gắnliền với các thuộc tính “pdC1”, , “pdCn” như là khái niệm miền và với các thuộctính “prC1”, , “prCm” như là khái niệm vùng

Định nghĩa 2.7 Chiến lược tiến hoá ES (Evolution Strategy) được định nghĩa là:

ES={(x, y) /xRP  yRW(x)}

theo các điều kiện sau đây:

Điều kiện 1: (x, y)ES zRW(x) \{y} (x, z)ESĐiều kiện 2: /ES/ = /RP/

Một chiến lược tiến hoá xác định cách thức giải quyết các thay đổi cơ bản Nó là mộttập các cặp lệnh, nơi mà mỗi cặp bao gồm một điểm giải quyết và chiến lược tiến hoá

cơ bản được xác định cho điểm giải quyết Điều kiện 1 yêu cầu cho mỗi điểm giảiquyết chỉ có một chiến lược tiến hoá cơ bản được quy định, trong khi điều kiện 2 yêucầu tất cả các điểm giải quyết được đưa vào tính toán

Vì vậy, để giải quyết sự thay đổi, quá trình tiến hoá cần phải xác định các câu trả lời

ở nhiều điểm giải quyết – các điểm rẽ nhánh trong quá trình giải quyết thay đổi nhậnmột đường đi khác nhau sẽ tạo ra kết quả khác nhau Mỗi câu trả lời có thể xảy ra tạimỗi điểm giải quyết là một chiến lược tiến hoá cơ bản Cách giải quyết chung baogồm một tập các chiến lược tiến hoá cơ bản, mỗi khi đưa ra câu trả lời cho một điểmgiải quyết, là một chiến lược tiến hoá Nó được sử dụng để tùy chỉnh quá trình tiếnhoá ontology Chúng ta gọi quá trình này - quá trình tiến hoá ontology theo địnhhướng bởi người dùng, trong đó người dùng là nhà thiết kế ontology có thể chỉ địnhmột chiến lược tiến hoá để biến đổi cho phù hợp với sự tiến hoá ontology theo nhucầu của họ Mối quan hệ giữa các khái niệm được thể hiện trong Hình 2.13 Các điểmgiải quyết và các chiến lược tiến hoá cơ bản của chúng bao gồm tất cả các cách có thểxảy ra mà nhà thiết kế ontology có thể chọn lựa để thay đổi ontology

Để đưa ra một tập các điểm giải quyết trong chiến lược tiến hoá, đầu tiên chúng taphải xem xét các loại thay đổi có thể áp dụng cho ontology Tiếp theo, phân tích cáckết quả của mỗi thay đổi trên ontology Chúng ta cô lập các thay đổi có thể gây ra cúpháp không nhất quán, và các thay đổi này không được áp dụng (ví dụ, thay đổiAddSubConcept không được phép áp dụng nếu nó tạo ra các chu trình trong hệ thốngphân cấp) Với mỗi cách giải quyết cụ thể, chúng ta xác định một chiến lược tiến hoá

cơ bản Với mỗi thay đổi cơ bản, chúng ta xác định một thủ tục có chứa các điểm giảiquyết gặp phải trong quá trình giải quyết thay đổi Mỗi điểm giải quyết tiêu biểu chomột điểm rẽ nhánh, và mỗi chiến lược tiến hoá cơ bản tiêu biểu cho một nhánh có thể

Báo cáo Biểu diễn tri thức và ứng dụng GVHD: PGS TS Đỗ Văn Nhơnxảy ra Việc lựa chọn chính xác một chiến lược tiến hoá cơ bản cho mỗi điểm giảiquyết sẽ tạo thành một chiến lược tiến hoá.

Định nghĩa 2.8 Sự phát sinh thay đổi được điều khiển bởi chiến lược tiến hoá,

ESChangeGeneration được định nghĩa là:

ESChangeGeneration: CHES  2CH,trong đó tham số thứ hai của hàm ESChangeGeneration là một chiến lược tiến hoágiám sát cách thức tạo ra các thay đổi bổ sung

Từ khi chiến lược tiến hoá đề xuất nhiều tính năng linh hoạt hơn trong việc giải quyết

sự thay đổi, chúng làm cho quá trình phát sinh thay đổi rất phức tạp Thay vì các mốiquan hệ nhân-quả (cause-effect) hai chiều giữa các thay đổi ontology như được minhhọa trong Bảng 2.1, thì bây giờ sự phụ thuộc hình thức giữa các thay đổi ontology làmột khối lập phương (3 chiều), trong đó chiều thứ ba là chiều chiến lược tiến hoá.Điều này được thể hiện ở bên trong Hình 2.14 Mỗi trục ứng với một chiều của sựthay đổi phát sinh

Ví dụ, trong Bảng 2.1 sự thay đổi AddSubConcept không gây ra bất kỳ sự thay đổi

bổ sung Tuy nhiên, nếu chiến lược tiến hoá cho điểm giải quyết RP8 cho phép hệthống phân cấp khái niệm sử dụng chiến lược tiến hoá cơ bản EES20, trong đó loại

bỏ nhiều đường đi cho mối quan hệ superconcept trong hệ thống phân cấp, thì sự thayđổi AddSubConcept có thể tạo ra thay đổi RemoveSubConcept Do đó, có một sựphụ thuộc giữa hai thay đổi này, kết quả là tạo ra một trục mới trong khối lậpphương Trục này đại diện cho phiên bản mới của bảng phụ thuộc thay đổi

Báo cáo Biểu diễn tri thức và ứng dụng GVHD: PGS TS Đỗ Văn Nhơn

Ví dụ chiến lược tiến hoá

Chúng ta tìm hiểu phương pháp tiếp cận thông qua một ví dụ về việc xóa một kháiniệm C trong một hệ thống phân cấp khái niệm Một phần của thuật toán với cácđiểm giải quyết tương ứng và các chiến lược tiến hoá cơ bản trong Hình 2.15 và Hình2.16

Mã giả của sự thay đổi RemoveConcept (xoá khái niệm) được thể hiện ở bên trongHình 2.15 và Hình 2.16

Hình 2.15 - Ngữ nghĩa thay đổi với thay đổi RemoveConcept (phần 1)

Báo cáo Biểu diễn tri thức và ứng dụng GVHD: PGS TS Đỗ Văn Nhơn

Phân tích giải thuật

Để giữ ontology trong trạng thái nhất quán sau khi loại bỏ khái niệm C, điểmgiải quyết nào cần được thực hiện? Theo Bảng 2.1 nếu ta xóa một khái niệmthì tác vụ RemoveSubConcept sẽ được thực hiện

Nếu thực hiện tác vụ RemoveSubConcept của C thì việc giải quyết các kháiniệm con của nó ra sao?, có thể bỏ luôn hay giữ lại?, nếu giữ lại thì gắn kếtchúng vào đâu? Từ đây nảy sinh điểm giải quyết RP1 trong Bảng 2.2, vàđiểm giải quyết này đưa ra ba chiến lược tiến hoá cho ta chọn, đó là EES1,EES2 và EES3 Với EES1 sẽ thực hiện dòng lệnh từ 6-15 trong giải thuật.Trong khi đó, EES2 và EES3 sẽ được minh họa trong thủ tục

RECONNECTCHILDREN(Concept C): từ dòng 42 – 51

Hình 2.16 - Ngữ nghĩa thay đổi với thay đổi RemoveConcept (phần 2)

Báo cáo Biểu diễn tri thức và ứng dụng GVHD: PGS TS Đỗ Văn Nhơn

Nếu thực hiện xóa khái niệm C ta sẽ làm gì với việc thừa kế các thuộc tínhmiền của C và của cha nó?, muốn vậy ta phải dùng điểm giải quyết RP3trong Bảng 2.2, và điểm giải quyết này đưa ra hai chiến lược tiến hoá cho tachọn đó là EES8, EES9 Hai chiến lược tiến hoá này sẽ được minh họa trongthủ tục RESOLVEPROPERTYDOMAIN(C): từ dòng 24 - 39

Việc thừa kế các thuộc tính vùng của C ta dùng điểm giải quyết RP3 đượcminh họa trong thủ tục RESOLVEPROPERTYRANGE(C): dòng 40, tương tự nhưthủ tục RESOLVEPROPERTYDOMAIN(C)

Sau khi khái niệm C rỗng, ta có thể xóa mối quan hệ giữa C và cha của nóbằng thủ tục DETACHSUPERCONCEPTS(Concept C): từ dòng 53 - 55

Nếu C không có con, ta có thể xóa các mối quan hệ với C bằng thủ tụcPREPAREREMOVELEAFCONCEPT(Concept C) : từ dòng 57 – 68

C Parent

Child2 Child1

Parent Child1 Child2

43

Root

45 45

Hình 2.18 – kết nối các con của C vào cha khác

Hình 2.17 – kết nối các con của C vào gốc

EES2

C Parent

Child1

Parent Child1Child2

48 4843

Parent

C 43

Child

Miền1 1 Miền2 1

Paren t

Hình 2.19 – Child thừa kế thuộc tính miền1 và miền2

Hình 2.20 – Child thừa kế thuộc tính miền của khái niệm C

Báo cáo Biểu diễn tri thức và ứng dụng GVHD: PGS TS Đỗ Văn Nhơn

Trong đó, để xóa thể hiện của C, ta dùng điểm giải quyết RP4

2.4.1.4 Chiến lược tiến hoá nâng cao

Trong thực tế, sự lựa chọn cách thức thay đổi (như xoá khái niệm) được giảiquyết dựa vào đặc điểm của trạng thái cuối đối với ontology (như độ sâu của

hệ thống phân cấp càng nhỏ càng tốt) hoặc về các đặc điểm của quá trìnhgiải quyết các thay đổi (như chi phí tối thiểu của các thay đổi phát sinh) Đểtùy biến quá trình tiến hoá ontology, nhà thiết kế ontology có thể chọn mộtchiến lược tiến hoá nâng cao Nó thể hiện một cơ chế ưu tiên, đáp ứng giữacác chiến lược tiến hoá khác nhau trong một tình huống cụ thể và nhà thiết

kế ontology dễ dàng chọn chiến lược tiến hoá cơ bản riêng

Một chiến lược tiến hoá nâng cao tự động kết hợp các chiến lược tiến hoá cơbản sẵn có để đáp ứng các điều kiện của người dùng Sau đây là tập cácchiến lược tiến hoá nâng cao liên quan đến việc sửa đổi ontology:

 Chiến lược tiến hoá nâng cao theo hướng cấu trúc - cố gắng giảm thiểu

một hệ thống phân cấp khái niệm Xây dựng chiến lược tiến hoá cơ bảnthích hợp cho các điểm giải quyết tác động đến hệ thống phân cấp kháiniệm

 Chiến lược tiến hoá nâng cao theo hướng quá trình xử lý - xác định

những gì đã được thay đổi và để thay đổi nó đòi hỏi phải làm thế nào vàcách thức các thực thể ontology tương tác với nhau ra sao Đây là chiếnlược cho phép nhà thiết kế ontology có thể dễ dàng theo dõi và hiểu rõtrình tự các thay đổi để thực hiện số lượng tối thiểu các bản cập nhật

 Chiến lược tiến hoá nâng cao theo hướng tần số xuất hiện - áp dụng

chiến lược tiến hoá sử dụng thường xuyên nhất hoặc gần đây nhất

2.4.2 Phương pháp tiếp cận khai báo với ngữ nghĩa thay đổi

Do sự thay đổi trong miền ứng dụng hoặc trong các yêu cầu của người sửdụng ontology tiến hoá theo thời gian, nên ontology mang tính phức tạp, đanxen cấu trúc, một thay đổi ontology có thể được giải quyết bằng nhiều cách

Ví dụ, sau khi loại bỏ khái niệm, các mối quan hệ subconcepts của nó có thểđược bảo tồn hoặc xóa theo Nếu chúng được bảo tồn, chúng phải được kết nốilại, hoặc với khái niệm cha của khái niệm đã bị xóa hoặc với khái niệm gốc.Cũng có thể xảy ra trường hợp người sử dụng muốn giữ lại một số mối quan

hệ subconcepts và loại bỏ phần còn lại của chúng Vì vậy, đối với các thay đổi

Báo cáo Biểu diễn tri thức và ứng dụng GVHD: PGS TS Đỗ Văn Nhơn

phức tạp, số giải pháp có thể tăng đáng kể Khi nhu cầu của một nhà thiết kếontology không thể dự đoán trước, thì cũng khó xác định chính xác cách thứcgiải quyết yêu cầu Vì vậy, đối với hệ thống tiến hoá ontology, để đạt tính hiệuquả, nó phải giải quyết hai vấn đề:

1 Làm thế nào nhà thiết kế ontology có thể xác định yêu cầu thay đổi.

2 Làm thế nào yêu cầu này có thể được thực hiện.

Vấn đề đầu tiên đòi hỏi phương pháp đáp ứng nhu cầu của nhà thiết kếontology sao cho cách thức khai báo được dễ dàng và chính xác Nó tráingược với tất cả các phương pháp tiếp cận hiện có, ở đó nhà thiết kế ontologychỉ có thể chọn một sự thay đổi từ một tập các thay đổi ontology được xácđịnh trước, mà không bao gồm tất cả nhu cầu của các nhà thiết kế ontology

Về vấn đề thứ hai, hầu hết các phương pháp tiếp cận hiện tại chỉ cung cấpcách thức giải quyết sự thay đổi, điều này thường là đơn giản Mặc dù cácchiến lược tiến hoá cung cấp linh hoạt hơn bằng cách cho phép nhà thiết kếontology kiểm soát và tùy chọn cách giải quyết sự thay đổi, nhưng họ khôngthể kiểm soát mọi khả năng xảy ra Để đạt được sự hoàn thiện của hệ thống,giải pháp không cần phải xác định trước các cách có thể giải quyết sự thay đổi,

mà cho phép hệ thống tự tính toán trên tất cả các cách đáp ứng các nhu cầucủa nhà thiết kế ontology

2.4.2.1 Phân tích ví dụ

Để minh họa quá trình giải quyết yêu cầu của người sử dụng cho một thay đổiontology, chúng ta sử dụng một ví dụ ontology rất đơn giản thể hiện trongHình 2.10(a) Giả sử rằng thông tin về Students là không cần thiết nữa, nhưngthông tin liên quan là PhD students và MSc students phải được giữ lại

Việc xác định chuỗi các yêu cầu thay đổi rất phức tạp Trình tự các yêu cầuthay đổi của chuỗi có thể không đáp ứng yêu cầu của một nhà thiết kếontology, ví dụ trước tiên loại bỏ khái niệm “Student” sẽ gây ra việc loại bỏcác khái niệm “PhD Student” và “MSc Student”, mà không đáp ứng được yêucầu của người sử dụng Hơn nữa, nhà thiết kế ontology phải hiểu ngữ nghĩacác thay đổi Ví dụ họ có thể hiểu rằng việc loại bỏ khái niệm “Student” cũng

sẽ gây ra việc loại bỏ khái niệm “BSc Student”

Nhà thiết kế ontology nên biết cách giải quyết sự thay đổi, nên tìm hiểu cácquyền thay đổi, dự đoán và giải quyết xung đột trung gian có thể xuất hiện vàtrình tự thay đổi đúng cách Hoạt động này rất tốn thời gian và dễ gây lỗi Nhucầu của họ khó thực hiện nếu ontology rất lớn (ví dụ như hàng nghìn kháiniệm) và khá phức tạp (ví dụ nhiều khái niệm phân cấp)

Mục tiêu của chúng ta là phát triển một hệ thống tiến hoá ontology, trong đóđáp ứng hai yêu cầu:

Báo cáo Biểu diễn tri thức và ứng dụng GVHD: PGS TS Đỗ Văn Nhơn

 Yêu cầu đầu tiên của nhà thiết kế ontology cho các thay đổi

Từ ví dụ trên, phải quy định khai báo chẳng hạn như:

RemoveConcept(“Student” ) and

not RemoveConcept(“PhD Student”) and

not RemoveConcept(“MSc Student”)

Nó không chỉ rõ các nhu cầu của nhà thiết kế ontology phải được thựchiện những gì và phải thực hiện như thế nào Nó không liên quan đếnkhái niệm “BSc Student” vì đây không phải là một phần của yêu cầu

 Yêu cầu thứ hai của nhà thiết kế ontology cho sự thay đổi phức tạp Nó

khó dự đoán mọi cách sẽ được giải quyết Vì vậy, giải pháp duy nhấtkhông phải là xác định làm thế nào để giải quyết sự thay đổi, mà để cho

hệ thống tự mình tìm mọi khả năng để thực hiện sự thay đổi và trình tựcho phù hợp Nó giống như trường hợp cấu hình lại hệ thống

2.4.2.2 Mô tả phương pháp tiếp cận khai báo

Phương pháp tiếp cận khai báo cho ngữ nghĩa thay đổi được thể hiện trongHình 2.22 Nhà thiết kế ontology phát biểu các yêu cầu thay đổi trong phươngpháp khai báo, một tập các yêu cầu thay đổi ontology được hỗ trợ bởi hệ thống(ví dụ một tập yêu cầu RemoveConcept(“Student”) and notRemoveConcept(“PhD Student”) and not RemoveConcept(“MSc Student”))(xem 1 trong Hình 2.22) Trong module hình thức hoá yêu cầu (xem 2), yêucầu này được chia thành hai tập thay đổi Tập thay đổi đầu tiên chứa các thayđổi được thực hiện (xem 3) trong khi tập thay đổi thứ hai bao gồm các thayđổi không được thực hiện (xem 4) Trở lại ví dụ trên, các yêu cầu thay đổiđược diễn ra bên trong như sau:

 posCH = {RemoveConcept(“Student” )}

 negCH = {RemoveConcept(“PhD Student”), RemoveConcept(“MScStudent”)}