Khái niệm Property là một trong những khái niệm không phù hợp trong ontology khi mô hình bằng các ngôn ngữ hướng đối tượng và UML. Vấn đề nảy sinh từ một điểm khác biệt rất lớn giữa Property và các khái niệm UML tương tự với nó là Association và Atribute. Bởi vì Property là một khái niệm độc lập, nó không thể được mô hình hóa trực tiếp bằng Association và Atribute, mà chỉ có thể được mô hình hóa bằng cách sử dụng một khái niệm độc lập từ UML. Khái niệm này phải là UML Class stereotype «RDFProperty», «OWLObjectProperty», hoặc «OWLDatatypeProperty». Tuy nhiên, Property phải có khả năng biểu diễn các mối quan hệ giữa các Resource (Class, Datatype, v.v trong UML) mà một UML Class không thể biểu diễn được. Nhìn lại định nghĩa của Property trong ODM, ta thấy rằng nó thực hiện việc biểu diễn các mối quan hệ thông qua range và domain của nó. Và ta thấy rằng trong Ontology UML Profile, việc biểu diễn các mối quan hệ tương ứng với ODM model phải được mô hình hóa với các stereotype «domain» và «range» của UML Association hoặc UML Attribute. Để làm cho các biểu đồ được dễ đọc hơn, kết hợp «range» là mối kết hợp một chiều (từ một Property đến một Class).
Hình 3.15: Các Ontology Property được biểu diễn trong một biểu đồ UML Class
OWL định nghĩa hai kiểu (lớp phụ) của Property - OWLObjectProperty và OWLDatatypeProperty. OWLObjectProperty, chỉ có thể có các cá thể trong range và domain của nó, được biểu diễn trong Ontology UML Profile như là Class stereotype «OWLObjectProperty». OWLDatatypeProperty được mô hình với Class stereotype «OWLDatatypeProperty».
Hình 42 là một ví dụ về một Class Diagram biểu diễn các ontology property được mô hình trong UML. Nó bao gồm 4 property: hai «OWLDatatypeProperty» (name và socialsecuritynumber) và hai «OWLObjectProperty» (play và colleague). Cộng tác với các UML Association «RDFSdomain» và «RDFSrange», hoặc các UML Attribute «RDFSdomain» và «RDFSrange», các property này được sử dụng để mô hình các mối quan hệ giữa các UML Class «OWLClass». Các giá trị đánh dấu mô tả các đặc tính bổ sung, ví dụ như «OWLObjectProperty» colleague là đối xứng và bắc cầu.
Có một vấn đề quan trọng mà phải được làm rõ trong biểu đồ này. Trong UML, các quan hệ được thể hiện bởi các Association (biểu diễn bằng đường thẳng) hay các Attribute. Các biểu đồ Ontology UML Profile có thể nhìn lộn xộn vì mỗi mối quan hệ yêu cầu một hình hộp và hai đường thẳng thể hiện đúng cách. Giải pháp được dùng ở đây sử dụng những ký hiệu đồ họa tiêu chuẩn, nhưng UML cho phép những ký hiệu đồ họa tùy biến cho một UML profile. Chẳng hạn, một ký hiệu đồ họa cho một Property có thể là một vòng tròn nhỏ với những đường thẳng, làm giảm bớt không gian yêu cầu trên một biểu đồ. Các tùy chọn bổ sung, như các màu phân biệt cho «OWLClass» (xanh lá cây) «OWLObjectProperty» (màu cam) và «OWLDatatypeProperty» (màu cam), có thể được dùng để tăng sự rõ ràng của biểu đồ. Nhằm làm tăng sự rõ ràng của biểu đồ, UML profile mà chúng ta sử dụng cho phép hai hình thức biểu diễn domain và range của một «OWLDatatypeProperty». Một ví dụ của hình thức thứ nhất (một UML Class với hai UML Association) là socialSecurityNumber, và một ví dụ của hình thức thứ hai (một Class với các Attribute như là domain hay range của nó) là name. Hình thức thứ hai chỉ được chấp nhận cho một «OWLDatatypeProperty» mà có range nhỏ hơn hoặc bằng 1. Do đó, nếu một «OWLDatatypeProperty» có range là 0..1 hay 1, hình thức sử dụng Attribute sẽ làm giảm sự lộn xộn.
3.4.3. Các Statement
OWLStatement là một khái niệm biểu diễn cho những mối liên kết cụ thể giữa những thể hiện của ODM – các cá thể và các giá trị dữ liệu. Trong UML, việc biểu diễn này sử dụng một Link (thể hiện của một Association) hoặc AttributeLink (thể hiện của một Attribute). Một Statement là một loại thể hiện của một Property, được biểu diễn bởi một UML Class stereotype («OWLObjectProperty» hoặc «OWLDatatypeProperty»). Bởi vì một thể hiện của một Class trong UML là một Object, một Statement trong Ontology UML Profile được mô hình với stereotype của object «OWLObjectProperty» hoặc «OWLDatatypeProperty» (stereotype của một Object trong UML phải phù hợp với stereotype của Class của nó). Các UML Link được sử dụng để biểu diễn subject và object của một Statement. Để chỉ ra rằng một Link là subject của một Statement, ta sử dụng LinkEnd stereotype «RDFsubject», trong khi object của Statement được chỉ ra bằng LinkEnd stereotype «RDFobject». Các LinkEnd stereotype được sử dụng bởi vì trong UML, Link không thể có một stereotype. Các Link này là các thể hiện thực sự của Property «RDFdomain» và
«RDFrange». Tóm lại, trong Ontology UML Profile, một Statement được biểu diễn như là một Object với hai Link – subject Link và object Link, được thể hiện trong hình 43. Các Person Mick Jagger và Keith Richards là các colleagues. Keith Richard chơi một loại nhạc cụ là guitar.
3.5. Sự ánh xạ của các ngôn ngữ và ontology dựa trên MDA
Tôi đã trình bày về các ontology metamodel dựa trên MOF của các ngôn ngữ ontology, cụ thể là ODM và OUP, được định nghĩa trong ngữ cảnh của kiến trúc MDA metamodeling. Tuy nhiên, một định nghĩa như thế thì không thể đầy đủ được, chúng cần phải tương tác với các ontology của thế giới thực, chẳng hạn như các ontology OWL. Rõ ràng là ta cần phát triển các phép biến đổi để hỗ trợ các quá trình chuyển đổi giữa các ngôn ngữ ontology MDA và OWL. Trên thực tế thì điều này cũng đã được OMG ODM RFP đề nghị, nhưng cả phương pháp hiện nay lẫn bản thân đặc tả phác thảo đều không cung cấp một giải pháp toàn diện để giải quyết vấn đề này. Trong phần này, chúng ta mô tả tất cả sự biến đổi này dưới dạng các không gian mô hình hóa và chuyên môn hóa. Vì vậy, đầu tiên chúng ta sẽ nhận dạng tất cả các không gian mô hình hóa liên quan tới vấn đề này và mô tả các mối quan hệ lẫn nhau của chúng. Bằng cách sử dụng các mối quan hệ này, chúng ta sẽ đề xuất các công cụ và kỹ thuật cho việc thực hiện các chuyển đổi này, và cuối cùng là mô tả một cách thực thi như vậy.
3.5.1. Mối quan hệ giữa các không gian mô hình hóa
Hình 44 sau đây đưa ra các không gian mô hình hóa được công nhận là quan trọng cho các chuẩn MDA và các ngôn ngữ ontology Web ngữ nghĩa hiện nay (như OWL và RDF(S)). Trong không gian mô hình hóa MOF, chúng ta đã định nghĩa ODM và OUP. Điều quan trọng cần phải lưu ý là ODM được định nghĩa ở tầng M2, trong khi OUP lại ở cả tầng M1 và tầng M2. Để cho rõ ràng thì ở hình 44 chúng ta để cả ODM và OUP ở tầng M2. Tầng M1 chứa các mô hình thế giới thực cụ thể, bao gồm các lớp và các thể hiện của các lớp đó. Chúng ta phải có nhiều hơn một tầng ontology ở tầng M1, và trong trường hợp của UML chúng ta có hai tầng ontology: một tầng cho các lớp và một tầng cho các thể hiện của chúng (các đối tượng). Đối với tất cả các tầng MDA, ta có thể sử dụng XMI, là một định dạng tương thích với XML cho việc chia sẻ metadata. Ở tầng dưới cùng (tầng M0, bên dưới tầng M1) là những thứ xuất phát từ thực tế.
Không gian mô hình hóa ontology bao gồm cả sự giới thiệu W3C cho ngôn ngữ OWL. Ngôn ngữ ontology này dựa trên XML và RDF(S) và vì thế định dạng XML được sử dụng cho việc trao đổi các ontology OWL. Trong không gian mô hình hóa này, chúng ta có thể nhận ra các lớp trừu tượng khác nhau để tìm kiếm các mối quan hệ của nó với không gian mô hình hóa MOF. Tầng nằm phía trên tầng dưới cùng được ký hiệu là O1. Trong tầng O1 chúng ta xây dựng các ontology, chẳng hạn như tạo các lớp, thuộc tính, các mối quan hệ và các ràng buộc. Các thể hiện ontology được đặt ở tầng O1 trong không gian mô hình hóa ontology. Ta sử dụng tính tương tự giữa tầng cao nhất đã được
định nghĩa trong không gian mô hình hóa ontology và các kết quả trong nghiên cứu của Decker (năm 2000). Trong bài báo đó, ngôn ngữ ontology (là OIL) được mô tả bằng cách sử dụng các ngôn ngữ ontology khác (như RDF(S)). Trên thực tế thì Decker và đồng nghiệp đã tạo ra metaontology. Cuối cùng chúng ta có thể nói rằng, có một metaontology ở tầng O2 xác định OWL. Thực sự, chúng ta đã khái quát hóa việc nghiên cứu mà trong đó tầng O3 cũng được định nghĩa sử dụng RDF(S).
Một số phát biểu quan trọng nhằm cung cấp các chuyển đổi giữa hai không gian mô hình hóa này:
1. Vai trò của MOF (M3) theo cách nhận thức là tương đương với vai trò của metametaontology (O3).
2. Vai trò của tầng O2 (metaontology) tương đương với vai trò của tầng metamodel (M2) (ví dụ như ODM và OUP). Vì thế có thể nói rằng cả hai tầng này đều chỉ định các ngôn ngữ ontology theo các không gian mô hình hóa khác nhau.
3. Tầng O1 có vai trò tương đương với vai trò của tầng model (M1) trong không gian mô hình hóa MOF. Một tầng ngôn ngữ (trong trường hợp này là M1) có thể chứa nhiều tầng ontology. Như vậy, hai tầng ontology trong tầng ngôn ngữ O1 (ontology schema và ontology instances) là tương đương với các class và object ở tầng M1 trong không gian mô hình hóa MOF.
Vì vậy ta có thể nói rằng: M3 ⇔ O3, M2 ⇔ O2 và M1 ⇔ O1.
Vì cả hai không gian mô hình hóa ontology và MOF đều sử dụng XML cho việc chia sẻ siêu dữ liệu nên chúng ta có thể tính đến một không gian mô hình hóa mới trong nội dung trình bày này. Tất nhiên đây là không gian mô hình hóa EBNF (Extended Backus–Naur form). Không gian mô hình hóa này cũng có tổ chức được phân lớp tương tự như ở không gian mô hình hóa ontology và MOF, nhưng tổ chức này được định nghĩa dưới dạng cú pháp (chứ không phải dưới dạng ngữ nghĩa). Tầng trên cùng của không gian mô hình hóa EBNF (tầng S3) là một cú pháp tự định nghĩa được biết đến phổ biến và còn được gọi là EBNF. Khi phân tích ngữ cảnh của không gian kỹ thuật XML được xác định một cách chính thức trong không gian mô hình hóa EBNF, ta thấy rằng tầng S2 có chứa một giản đồ của các giản đồ (siêu giản đồ - metaschema). Metaschema này xác định tính hợp lệ của các tài liệu định nghĩa XML Schema. Tầng S1 định nghĩa miền đặc trưng của các từ vựng XML (các giản đồ) và các tài liệu XML cụ thể. Vì thế ta có thể rút ra kết luận về tính tương đương giữa hai không gian mô hình hóa (ontology và EBNF) như sau: S3 ⇔ O3, S2 ⇔ O2 và S1 ⇔ O1. Cuối cùng ta có ba mối quan hệ giống nhau tồn tại giữa các không gian mô hình hóa MOF và EBNF: S3 ⇔ M3, S2 ⇔ M2 và S1 ⇔ M1.
Trong phần trước chúng ta đã giải thích về các giải pháp dựa trên khái niệm cho việc chuyển đổi giữa các ngôn ngữ ontology dựa trên MOF (là ODM và OUP) và OWL. Trong phần này chúng ta trình bày một ví dụ về sự thực thi để chuyển đổi một ontology dựa trên OUP thành ontology OWL tương đương với nó. Việc chuyển đổi này cung cấp cho chúng ta các ontology Web ngữ nghĩa có thể được sử dụng trong các ứng dụng Web ngữ nghĩa trong thế giới thực.
Chi tiết của sự thực thi
Ý tưởng chính của việc có một profile UML cho việc phát triển ontology là sử dụng các công cụ UML có sẵn. Thực tế thì các công cụ UML hiện tại (như Rational Rose của IBM và Poseidon dành cho UML) đều hỗ trợ chủ yếu cho chuẩn XMI – chuẩn MDA dựa trên XML cho việc chia sẻ metametamodel, metamodel và model. Vì XMI dựa trên XML nên có thể sử dụng XSLT để chuyển đổi các tài liệu XMI thành các tài liệu đích. Những tài liệu đích này có thể được soạn thảo trong một ngôn ngữ ontology, như OWL chẳng hạn, là ngôn ngữ đã có cú pháp XML của nó. Mặt khác, khi chúng ta sử dụng cách tiếp cận dựa trên cơ sở của nguyên lý XSLT thì chúng ta không cần điều chỉnh công cụ UML, thay vào đó chúng ta chỉ cần áp dụng một XSLT cho output của công cụ UML. Vì thế chúng ta có thể sử dụng thủ tục XML/XSLT đã được định nghĩa tốt như trình bày ở hình 3.16 sau đây.
Hình 3.16: Sử dụng nguyên lý XSLT: các mở rộng của các công cụ UML hiện tại cho việc phát triển ontology
Một công cụ UML có thể export một tài liệu XMI, mà tài liệu này có thể được sử dụng như input cho bộ xử lý XSLT (ví dụ như Xalan; http://xml.apache.org). Tài liệu OWL là sản phẩm output của quá trình xử lý ở trên và định dạng của tài liệu OWL này có thể được import vào một công cụ chuyên dụng trong việc phát triển ontology (chẳng hạn như Protégé), tại đó nó có thể được cải tiến thêm nữa. Mặt khác, vì ta thu được một tài liệu OWL, ta không cần sử dụng bất cứ công cụ ontology nào; tài liệu thu được có thể được sử dụng như là ontology cuối cùng.
XSLT mà chúng ta đã thực thi cho việc ánh xạ các mô hình OUP thành các OWL ontology bao gồm một tập các quy tắc (chẳng hạn như các XSLT template), các quy tắc này phù hợp với cấu trúc UML XMI của các mô hình OUP và chuyển đổi chúng thành các thành phần OWL tương đương. Trong quá trình phát triển các quy tắc này, chúng ta gặp phải một số trở ngại nghiêm trọng nảy sinh từ những sự khác biệt rõ ràng giữa các định dạng nguồn và đích. Tôi đã ghi nhận một số trở ngại như sau:
- Cấu trúc của một tài liệu UML XMI là khá rắc rối, bởi vì nó chứa một mô tả đầy đủ của mô hình UML mà nó biểu diễn, ví dụ như các class, attribute, relation (association, dependency, và generalization), và các mô tả stereotype. - Trong một số trường hợp, OUP sử dụng nhiều hơn một cấu trúc UML để mô hình một phần tử OWL. Ví dụ, để mô hình ràng buộc someValuesFrom sử dụng OUP (xem hình 51), ta cần 3 UML class và 3 relation (một association và hai dependency). Điều này là đặc biệt khó khăn, bởi vì mỗi cấu trúc UML có một stereotype khác nhau.
- Các công cụ UML chỉ có thể vẽ ra các mô hình UML, chúng không có khả năng kiểm tra tính đầy đủ của một OUP ontology. Do đó, cần phải có XSLT để thực hiện việc kiểm tra các tài liệu XMI. Đây là cách duy nhất để tránh việc sinh ra các OWL ontology không chính xác.
- XSLT phải tạo ra sự khác biệt giữa các class được định nghĩa trong các class khác (và không thể được tham chiếu qua ID của chúng) với các class có thể được tham chiếu bằng ID. Theo đó, ta đã bao gồm giá trị tag odm.anonymous trong OUP, nó sẽ giúp chúng ta phân biệt giữa hai trường hợp này.
TÀI LIỆU THAM KHẢO
[1]. Các bài giảng của Thầy PGS. TS. Đỗ Văn Nhơn, Trường Đại học Côngnghệthôngtin, 2012.
[2]. GS. TSKH. Hoàng Kiếm, TS. Đỗ Văn Nhơn, TS. Đỗ Phúc, 2002, Các hệ cơ sởtri thức, Đạihọc Quốcgia,TP.HCM.
[3]. TS. Đỗ Văn Nhơn, 1996, Giải đề trên mạng tính toán, Luận văn Thạc sỹ,Đại họcKhoa họcTự nhiên,TP.HCM.
dựng và phát triển các mô hình biểu diễn tri thức cho các hệ giải toán tự động, LuậnánTiến sĩ, Đạihọc KhoahọcTự nhiên, TP.HCM.
[5].Dragan Gasevic, Dragan Djuric, Vladan Devedzic, Model Driven
Architecture and Ontology Development, Springer, 2006, Chapter 4, 7, 8, 9,