Ultimate mashup – Các dịch vụ Web và Web ngữ nghĩa (semantic Web), Phần 4: Tạo một bản thể luận

Lựa chọn một cách tự động giữa các dịch vụ và các phần của một dịch vụ với XML dựa trên ngôn ngữ bản thể luận web (OWL)

Loạt bài này mô tả cách tạo một ứng dụng Mashup cho phép kiểm soát đối với các dữ liệu được hiển thị lại cho người sử dụng, để làm điều đó, bạn cần phải xây dựng một cách có đầu óc. Bây giờ bạn biết hiển thị thông tin trong RDF như thế nào, bạn có thể bắt đầu tạo một bản thể luận (ontology) bằng cách sử dụng Web Ontology Language (OWL) dựa trên XML. Việc này cho phép bạn chọn lựa giữa các dịch vụ và các bộ phận của các dịch vụ một cách tự động.

Nicholas Chase, Tác giả tự do, Site Dynamics Interactive Communications

Nicholas Chase đã phát triển trang web cho các công ty lớn như Lucent Technologies, Sun Microsystems, Oracle, và Tampa Bay Buccaneers. Nick đã từng là một giáo viên vật lý ở trường phổ thông, một nhà quản lý thiết bị phóng xạ mức thấp, một nhà biên tập tạp chí khoa học viễn tưởng trực tuyến, một kỹ sư đa phương tiện, một hướng dẫn của Oracle, và một trưởng phòng công nghệ của một công ty tương tác truyền thông. Nick là tác giả của một số sách



08 03 2007 (Xuất bản lần đầu tiên vào ngày 20 09 2009)

Trước khi bạn bắt đầu

Bài viết này cho những độc giả muốn hiểu thêm về việc phát triển các bản thể luận, hoặc sự phân lớp các khái niệm và chúng liên quan đến web ngữ nghĩa như thế nào. Nó cũng dành cho những độc giả muốn hiểu thêm về các lựa chọn suy diễn sẵn có trên ngôn ngữ Web Ontology Language (OWL). Bài hướng dẫn này giả định rằng bạn đã biết các khái niệm về khung mô tả tài nguyên (Resource Description Framework - RDF), bạn có thể đọc lại phần 3 của loạt bài viết này. (xem Tài nguyên). Bạn cũng nên có hiểu biết chung về XML nhưng chúng ta sẽ không đi sâu vào những khái niệm này.

Các kỹ năng lập trình không là điều kiện để hoàn thành bài viết này.

Giới thiệu về loạt bài này

Bạn không thể thay đổi hoàn toàn trang web mà không nhảy vào một trang web mà ở đó cho phép bạn truy cập đến các dữ liệu của nó thông qua một API dựa trên các dịch vụ web, hoặc sử dụng dữ liệu từ một trang khác thu được thông qua API dựa trên các dịch vụ web. Khi bạn xem xét ưu điểm của thông tin hiện có trong các ứng dụng của riêng bạn, điều đó không chắc là có sự ngạc nhiên lớn nào. Điều đó không chỉ là vấn đề thời gian trước khi ai đó bắt đầu kết hợp dữ liệu từ các hệ thống khác nhau để tạo ra vài thông tin trọn vẹn. Các ứng dụng này được gọi là các Mashup, các Mashup là ứng dụng gần đây nhất trên web, từ các trang dựa trên cộng đồng tới các trang tìm kiếm chuyên biệt đều ánh xạ Mashup.

Các Mashup hầu hết là hữu dụng, chúng có điểm chung là được phát triển với tập các dịch vụ riêng biệt. Nếu một trong các dịch vụ thay đổi hoặc nếu sở thích của bạn với các loại dịch vụ thay đổi thì bạn sẽ có nhiều việc phải làm.

Mục đích của loạt bài hướng dẫn này (xem Tài nguyên) là tạo một ứng dụng Mashup để người dùng có thể thêm hoặc hủy các dịch vụ một cách tùy ý và hệ thống sẽ không biết được người dùng đã làm gì với chúng. Các bước tiến hành như sau:

Phần 1 đã giới thiệu khái niệm của các Mashup, thể hiện chúng làm việc như thế nào và xây dựng một phiên bản đơn giản của nó như thế nào. Bạn cũng đã nhận thấy các vấn đề về hiệu suất quan trọng khi thực hiện gọi hàng tá các trang web tiềm ẩn.

Phần 2 giải quyết vài vấn đề về sử dụng pureXML™ với các khả năng của IBM® DB2® để xây dựng một nơi lưu giữ XML, nơi này lưu trữ các kết quả của các yêu cầu trước đó và cũng cho phép bạn lấy thông tin đặc trưng.

Cuối cùng, bạn sẽ cần phải dùng các bản thể luận, hoặc các từ vựng để xác định các khái niệm và các mối quan hệ giữa chúng. Vì vậy ở phần 3 của tiến trình ta bắt đầu quá trình đó bằng việc tìm hiểu về RDF và RDFS, hai thành phần quan trọng của ngôn ngữ bản thể luận web (Web Ontology Language-OWL). Các vấn đề này được thảo luận trong phần 4. Ở phần 5, bạn đưa các bản thể luận mà bạn đã tạo ra ở phần 4 và sử dụng chúng để cho phép những người dùng thực hiện thay đổi các nguồn thông tin bên ngoài.

Trong phần 6, thực sự có những điều thú vị. Tại đó, bạn có một ứng dụng đang thực thi và khung làm việc trong đó, do vậy hệ thống có thể sử dụng suy dẫn ngữ nghĩa để hiểu các dịch vụ một cách tùy ý. Trong phần này, bạn đưa ra kiểm soát người dùng, cho phép họ ánh xạ các dịch vụ mới vào bản thể luận, và nhấc hoặc chọn dữ liệu được dùng với một Mashup tùy ý.

Giới thiệu về bài viết này

Phần trước của loạt bài này đã giải thích một Mashup là gì và bạn có thể sử dụng nó để kết hợp dữ liệu từ nhiều nguồn như thế nào. Mục đích của loạt bài này là cung cấp một hệ thống. Hệ thống đó xây dựng trên trí tuệ, giống như khả năng chuyển một dịch vụ này sang dịch vụ khác mà không biết chính xác thông tin được biểu diễn như thế nào trước đó. Để làm được việc đó, bạn sẽ cần một phương pháp để xác định các khái niệm như kho sách (bookstore), DVD, giá, v.v... Xây dựng trên phần thảo luận khung mô tả tài nguyên (Resource Description Framework) ở phần 3. (xem Tài nguyên), ở phần 4 bạn sẽ tạo một bản thể luận, hoặc phân lớp các khái niệm, sử dụng ngôn ngữ Web Ontology Language (OWL).

Trong suốt bài học của bài viết này, bạn sẽ học:

  • Các bản thể luận là gì
  • Ngôn ngữ Web Ontology Language là gì
  • Các đặc trưng khác của OWL
  • Tạo một bản thể luận như thế nào
  • Tạo các lớp con như thế nào
  • Các kiểu khác nhau của các thuộc tính OWL
  • Thêm thông tin vào bản thể luận để cho phép suy diễn như thế nào
  • OWL-S và ý nghĩa cho phân lớp các dịch vụ Web gì

Trong bài này, bạn sẽ xây dựng một bản thể luận mẫu cho một kho sách. Nó cho phép bạn xem xét chuyển một kho sách từ một nơi này đến nơi khác như thế nào ở phần 5

Các điều kiện tiên quyết

Theo đoạn mã trong hướng dẫn này, bạn cần phải cài đặt và kiểm tra các phần mềm sau đây:

  • IBM® DB2® 9 (thường được gọi là "Viper"): Cơ sở dữ liệu quan hệ này cũng chứa những khả năng XML quan trọng, bạn sẽ cần chúng cho bài viết này. Bạn có thể tải về một phiên bản dùng thử của DB2 9: DB2 Enterprise 9 hoặc DB2 Express-C 9, một phiên bản miễn phí của máy chủ dữ liệu DB2 Express 9.
  • Apache Tomcat hoặc một máy servlet khác: Bạn sẽ xây dựng các ứng dụng web sử dụng các servlet, vì vậy bạn cần có một máy servlet chẳng hạn như Apache Tomcat. Nếu bạn chọn xây dựng ứng dụng trên một môi trường khác, hãy chắc chắn rằng bạn đã nắm rõ nó trong lòng bàn tay. Tải về apache-tomcat-5.5.17.zip và cài đặt vào một thư mục với tên thư mục không chứa dấu cách.
  • Bạn xây dựng bài học này với Java: Apache Tomcat 5.5, yêu cầu Java 1.5 hoặc cao hơn. Hãy tải về J2SE SDK.
  • Để làm mọi việc dễ dàng hơn, bạn cần sử dụng một IDE chẳng hạn như Eclipse hoặc IBM Rational™ Web Developer cho phát triển của mình. Bạn có thể tải về Eclipse ở Eclipse.org, tải về một phiên bản dùng thử của Rational Web Developer, hoặc sử dụng môi trường phát triển mà bạn thích. Chúng ta sẽ không làm những gì quá sức với trình biên dịch và việc phát triển

Tổng quan

Trước loạt bài này, bạn đã tạo các khởi đầu cho ứng dụng của mình. Hãy xem bạn đang ở đâu và sẽ đi đến đâu ở bài viết này.

Nhìn lại các phần trước

Mục tiêu của các bài viết này là tạo ra một ứng dụng Mashup -- một ứng dụng sử dụng dữ liệu từ nhiều nguồn, thông thường sử dụng các dịch vụ web -- điều đó cho phép người dùng chọn thông tin đã biểu diễn. Trong phần 1 của loạt bài viết này, bạn đã tạo ứng dụng Mashup, một Java servlet thực hiện gọi các dịch vụ web đã xác định một cách tùy ý và hiển thị thông tin của chúng dựa trên một mẫu HTML/XML. Đó là dữ liệu bạn bạn muốn người dùng kiểm soát.

Nhưng trước khi có điều trên, có vài điều bạn cần làm. Để có một trang điển hình giống như trong hình 1 có thể đưa hàng tá các yêu cầu HTTP, điều đó có thể không được chấp nhận trong thế giới thực. Để giải quyết vấn đề, trong phần 2 bạn đã bắt đầu lưu các yêu cầu như HTML nguyên gốc vào DB2 bằng cách sử dụng các khả năng pureXML mới của DB2 (xem Tài nguyên). Điều này cho phép bạn kiểm tra cơ sở dữ liệu với các kết quả của một truy vấn riêng trước khi bạn phải ra khỏi và yêu cầu lại nó. Tất cả điều này là tốt, nhưng để xây dựng trí tuệ vào hệ thống, bạn cần tìm ra một cách để đặc tả các khái niệm và các biểu diễn XML của chúng trong một máy có thể đọc được. Bạn sẽ làm được điều đó ở bài học này bằng các sử dụng ngôn ngữ bản thể luận web (OWL). Nhưng để làm điều đó, trước tiên bạn có một nền tảng về khung mô tả tài nguyên (Resource Description Framework - RDF). Ở phần 3, bạn đã học tất cả các đặc điểm RDF, bạn sẽ cần phải bắt đầu xác định các khái niệm ở đây, trong phần 4.

Hình 1. Trang cuối cùng
Trang cuối cùng

Bộ làm tươi RDF

RDF được thiết kế để cung cấp một cách để xác định các khái niệm khác nhau, cho phép bạn tạo các tài nguyên và các thuộc tính đã liên kết của chúng. Xem ví dụ 1.

Ví dụ 1. Một tài liệu RDF đơn giản
<rdf:RDF 
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:dc="http://purl.org/dc/elements/1.1/">

   <rdf:Description rdf:about="http://www.chaosmagnet.com/blog">

      <dc:creator>Nicholas Chase</dc:creator>
      <dc:title>Chaos Magnet</dc:title>
      <dc:description>
           The personal and professional ramblings of technology 
           author Nicholas Chase
      </dc:description> 
      <dc:date>2006-06-30</dc:date>

   </rdf:Description> 

</rdf:RDF>

Ở đây bạn thấy một bản mô tả một tài nguyên được xác định bởi URI http://www.chaosmagnet.com/blog (và cũng là định vị ở đó). Bạn đang mô tả các thuộc tính, chẳng hạn như tác giả (creator) và tiêu đề (title) được xác định ở không gian tên (namespace) http://purl.org/dc/elements/1.1 .

Ngôn ngữ lược đồ RDF cung cấp các cách xây dựng RDF để làm cho nó tạo ra các khái niệm dễ dàng hơn (xem ví dụ 2).

Ví dụ 2. Sử dụng RDFs để tạo các lớp
<rdf:RDF 
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
   xml:base="http://www.example.com/mashup/">

   <rdf:Description rdf:ID="Service">
      <rdf:type rdf:resource=
               "http://www.w3.org/2000/01/rdf-schema#Class"/>
   </rdf:Description>

   <rdf:Description rdf:ID="SOAPService">
      <rdf:type rdf:resource=
               "http://www.w3.org/2000/01/rdf-schema#Class"/>
      <rdfs:subClassOf rdf:resource="#Service" />
   </rdf:Description>

   <rdf:Property  rdf:ID="endpoint">
      <rdfs:domain rdf:resource="#Service"/>
      <rdfs:range rdf:resource=
                "http://www.w3.org/2001/XMLSchema#anyURI"/>
   </rdf:Property>

   <SOAPService rdf:ID="Amazon.com">
      <endpoint>
         http://soap.amazon.com/onca/soap?Service=AWSECommerceService
      </endpoint>
   </SOAPService>

</rdf:RDF>

Trong trường hợp này, bạn tạo một lớp, SOAPService, đó là lớp con của một lớp thứ hai Service. Bạn cũng tạo một thuộc tính endpoint, và chỉ ra rằng nó chỉ có thể xuất hiện ở một lớp Service, và nó phải chứa dữ liệu phù hợp với định danh lược đồ XML của một URI.

Cuối cùng bạn tạo một thể hiện của lớp SOAPService (và lớp Serice) thể hiện đó chứa thuộc tính endpoint.

Các lớp, các thuộc tính các các cá thể đã tạo thuộc vào miền không gian tên cơ sở, http://www.example.com/Mashup/.

Bạn sẽ sử dụng các kỹ thuật giống như thế này để xây dựng các lớp, các thuộc tính và các cá thể cho bản thể luận của mình hơn là xây dựng RDF nguyên gốc. Chúng dựa vào các lớp, các thuộc tính, v.v.. từ không gian tên OWL.

Một bản thể luận là gì?

Khái niệm gốc của bản thể luận giống như nghiên cứu về "nó là gì". Chuyển tiếp từ Aristotle và Plato, tuy nhiên, giờ đây hầu hết bản thể luận được xem như là một phân lớp các khái niệm. Có nhiều khái niệm về một bản thể luận. Bởi vì thực tế là thế giới thật phức tạp. May thay, bộ não con người cũng điều chỉnh được sự phức tạp này. Bạn có thể nhận ra chiếc áo sơ mi của mình, và bạn cũng biết bạn mặc nó trên mình chứ không phải ở chân. Điều này dường như thật đơn giản. Đó là áo sơ mi, bạn sẽ không làm điều gì khác với nó được. Nhưng bạn chỉ biết rằng, vì bạn là con người và có lẽ con người thì mặc những chiếc áo sơ mi trong cuộc sống của mình.

Tất nhiên máy tính thì không biết được điều này. Nó cũng không biết rằng bạn không nên mặc đồ sọc và kẻ caro hoặc các sọc ngang vì chúng làm bạn trông béo lên. Vì vậy thật là khó để một máy tính chọn ra một tủ quần áo cho bạn mà không có hỗ trợ. Một bản thể luận có thể xác định một số khái niệm cho máy tính chẳng hạn như các cái mũ, các đôi giầy, các phong cách, các kích cỡ và các thông tin có liên quan và làm thế nào để chúng phù hợp với nhau.

Thật lý tưởng, một máy tính có thể nhận ra các khái niệm này, và gợi ý áo T-shirt đi với quần jean trái ngược với gợi ý giầy cao gót và áo yếm. (Sau đó các món đồ có thể xấp xỉ vào một số trường hợp, nhưng bạn phải lập trình vào bản thể luận.)

Các bản thể luận cũng được ứng dụng vào các giải pháp chuyên nghiệp. Một tìm kiếm với "bản thể luận trong ngành công nghiệp" mang đến các kết quả về máy tự động, điện lực, kim loại và các ngành công nghiệp sản xuất và đó chỉ là ở trang đầu tiên! Trong trường hợp này, các bản thể luận được sử dụng thường xuyên không những để giảng dạy cho các máy tính làm được điều đó mà còn chọn ra thông tin trong trí óc của những nhân viên nhiều kinh nghiệm để tri thức của họ có thể được chuyển cho những người khác.

Ở trường hợp của bạn, bạn sẽ tạo một bản thể luận để xác định các khái niệm dưới các dịch vụ web mà ứng dụng của bạn sử dụng để hệ thống có thể biết rằng ý của bạn là gì nếu bạn nói bạn muốn một giá cả. (Hoặc ít nhất nó cho biết làm thế nào để tìm nó trong dịch vụ).

OWL là gì?

Bạn đã học đến đây trong bài viết mà không có một từ nào nói về web ngữ nghĩa, nhưng thực sự là tại sao bạn ở đây, vì vậy hãy nói về nó.

Web ngữ nghĩa có nghĩa là một nơi mà trong đó các quyết định thông minh có thể được thực hiện. Nó có thể có nghĩa gì đó đơn giản như là một tìm kiếm có từ khóa là một xâu bạn đặt vào, tìm kiếm đó trả lại những gì bạn muốn thay vì mọi thứ. Hoặc nó có thể là một thứ gì đó phức tạp như là kết hợp các lược đồ cho nhiều người hoặc tìm ra điều gì xã hội nhất trí về một chủ đề cụ thể ngày hôm nay chứ không phải là này hôm qua.

Để làm được điều đó, bạn sẽ biểu diễn thông tin theo cách mà các máy tính có thể hiểu được nó. Thí dụ, một ứng dụng tìm một ngày phù hợp cho gia đình bạn xum họp cần hiểu thông tin đó biểu diễn cho một lịch biểu mà mọi người có thể tham gia và các khoảng cách giữa họ, các sân bay phù hợp, lịch trình của hãng hàng không, giá cả, các dị ứng, thời tiết và v.v... (Được rồi, có thể bạn không có quá kỹ càng về kế hoạch xum họp gia đình của mình nhưng nếu bạn có một máy tính thực hiện việc đó, bạn có thể làm nó đúng)

Để làm cho tất cả thông tin đó sẵn có trong một cấu trúc máy có thể đọc được, bạn cần một cách để mã hóa các bản thể luận của tất cả thông tin này vào một cách chuẩn. Phần 3 đã nói về RDF, một chuẩn cho biểu diễn thông tin (xem Tài nguyên). Bây giờ bạn sẽ tận dụng điều đó để biểu diễn các khái niệm.

Bạn chỉ có thể đưa tất cả các thông tin và biểu diễn nó như RDF, nhưng bạn cần một cách để máy tính có thể thực hiện các suy luận. Ví dụ, bạn có thể biết Judy đang sống ở Francesville và Pauline đang sống ở Indianapolis. Bạn cũng biết rằng Francesville ở bang Indiana và Indianapolis cũng ở bang Indiana. Nhưng chẳng có gì về RDF để cho phép máy tính thực hiện suy luận rằng Pauline và Judy sống cùng một bang. Ngôn ngữ WOL là một ứng dụng của RDF cung cấp một cách mã hóa thông tin này để máy tính có thể thực hiện các suy luận này.

Ồ, còn về chữ viết tắt. Không, nó không khớp với tên. Đây là điều chủ tâm bởi vì OWL dễ cho việc nói và cung cấp các logo hơn là WOL. Nó có nghĩa là tôn vinh dự án "One World Language" của William H. Martin từ những năm 1970. (Bạn cũng sẽ tìm các tài liệu tham khảo tới Winnie the Pooh, nhưng nhìn bề ngoài đó không phải là tài liệu gốc thực sự.)

Các đặc trưng khác của OWL

OWL là một ngôn ngữ có các mục đích bù nhau nhưng mâu thuẫn. Bản thân nó làm cho nó có thể miêu tả nhiều khái niệm và các mối quan hệ khác nhau nhưng ở cùng một thời điểm, làm cho việc dùng các khái niệm đó yêu cầu phần mềm có thể thực hiện việc suy luận chúng.

Thật không may, một ngôn ngữ cung cấp nhiều lựa chọn, khó hơn viết một phần mềm tính đến tất cả nó.

OWL giải quyết vấn đề này bằng việc cung cấp ba kiểu hoặc các mức khác nhau của OWL:

  • OWL đầy đủ (OWL Full): kiểu có ý nghĩa nhất trong ba kiểu. OWL đầy đủ cơ bản cho phép bạn làm bất cứ điều gì mà RDF cho phép. Bạn có thể xác định các lớp ngay khi đang chạy, sử dụng các lớp như là các thuộc tính và các cá thể, xây dựng các bản thể luận không nhất thiết phải quyết định, nghĩa là một chương trình có thể không có đủ thông tin để trả lời tất cả các câu hỏi được yêu cầu bởi dữ liệu. Ngay cả các chi tiết kỹ thuật OWL chỉ ra rằng nó không giống một công cụ đơn sẽ hỗ trợ tất cả OWL đầy đủ.
  • OWL DL: DL đại diện cho mô tả logic có nhiều ý nghĩa của OWL đầy đủ, nhưng yêu cầu các bản thể luận được quyết định. Nó cũng đòi hỏi tất cả các lớp được xác định rõ ràng và có các hạn chế trên một vài đặc tính nâng cao hơn của OWL.
  • OWL rút gọn (OWL Lite): OWL rút gọn là một phiên bản con của OWL. Nó dành cho những ai cần tạo một bản thể luận đơn giản hơn và cho những ai không cần đến tất cả các tính biểu cảm của ngôn ngữ. Ví dụ, OWL rút gọn cho phép bạn chỉ rõ một thuộc tính phải tồn tại cùng một đối tượng và phải có một giá trị. Nhưng bạn không thể xác định giá trị đó là gì. Tất nhiên đây là các kiểu dễ nhất để xây dựng các công cụ cho nó.

Các kiểu này lắp vào với nhau nếu bạn phản đối trò chơi chữ. Một bản thể luận OWL rút gọn hợp lệ cũng là một bản thể luận OWL DL và OWL đầy đủ hợp lệ. và một bản thể luận OWL DL hợp lệ cũng là một bản thể luận OWL đầy đủ.

Bạn định thực hiện điều gì

Trong bài viết này, bạn sẽ xây dựng một bản thể luận khá đơn giản cho một trong những trường hợp sử dụng của ứng dụng Mashup. Cụ thể, bạn sẽ xây dựng một bản thể luận xác định vài khái niệm liên quan khi giao dịch với kho sách trực tuyến.

Điều đó có thể không giống nhiều trong lược đồ lớn các sự kiện, nhưng trong khi làm điều như vậy bạn sẽ nhận ra rằng hầu hết các tính năng được OWL cung cấp. Một bản thể luận đầy đủ mọi kiểu dịch vụ bạn phải gặp yêu cầu không gian nhiều hơn là bài viết này cho phép. Cuối bài viết này, bạn có thể đưa các tri thức đã đạt được và xây dựng một bản thể luận độc đáo bất kỳ.


Cấu trúc của bản thể luận

Bước thứ nhất trong việc xây dựng một bản thể luận là bạn hiểu ban đang xây dựng cái gì. RDF (và bằng OWL mở rộng) là một ngôn ngữ rất có ý nghĩa, nhưng phải trong cấu trúc văn bản của nó. Nó không thực hiện những điều dễ hình dung một cách đặc biệt. Vì vậy hãy bắt đầu bằng việc xem xét cấu trúc như bạn thấy nó.

Cấu trúc cơ bản

Trong bài này, chúng ta không có đủ không gian để ghi chép việc tạo cùng một bản thể luận đầy đủ cho các kho sách trực tuyến, ít nhiều cho mọi kiểu dịch vụ bạn có thể gặp. Nhưng bạn có thể tạo một mẫu đại diện. Cụ thể, bạn muốn xác định các khái niệm sau đây trong hình 2.

Hình 2. Cấu trúc cơ bản
Cấu trúc cơ bản

Bắt đầu ở góc trên trái, bạn có một Service, các lớp con như là một kho Store, các lớp con như là một kho sách Bookstore. Các kho Store chứa các món đồ StockItems, mỗi món đồ có một giá itemPrice và tương ứng có một stockedProduct riêng. Trong trường hợp này, sản phẩm đó có thể là Book hoặc một Movie. Nếu nó là sách Book, thì nó phải có ít nhất một tác giả Author. Author đó là một lớp con của lớp Person, một lớp cũng chứa đạo diễn phim (Directors).

Thúc đẩy các khả năng OWL

Hình 2 chỉ ra bạn đang xử lý các lớp (class) nào. Nhưng nếu đã có tất cả những gì bạn muốn chỉ định, bạn sẽ không cần OWL, Thay vì bạn có thể chỉ ra tất cả với RDF và lược đồ RDF.

Không, bạn cần OWL với lí do nó cung cấp các khả năng. Ví dụ, bạn có thể xây dựng một cách logic phát biểu rõ rằng một Book có thể được định danh duy nhất bằng một số ISBN của nó. Mặt khác, nếu hai cuốn sách riêng biệt có cùng một số ISBN thì chúng là sách giống nhau. Bạn cũng có thể xây dựng một cách linh động với các cấu trúc khác do các dịch vụ khác nhau cung cấp. Ví dụ, bạn có thể chỉ rõ rằng các lớp WriterAuthor là cùng một lớp.

Sau đó bạn sẽ thấy các khả năng khác.

Bản thể luận cơ bản

Bạn đã biết nó là gì mà bạn đang cố gắng hoàn thành. Vì vậy bạn có thể bắt đầu xây dựng bản thể luận. Trước tiên hãy tạo ra các lớp và một vài cá thể để bạn có thể xem những thứ đó phù hợp với nhau như thế nào.

Tạo bản thể luận

Bước thứ nhất là tạo một tài liệu bản thể luận thực sự. Trong nhiều trường hợp, nó cũng giống như các tài liệu RDF mà bạn đã có (xem ví dụ 3).

Ví dụ 3. Tạo một bản thể luận
<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [
   <!ENTITY store  "http://example.com/stores#" >
   <!ENTITY owl  "http://www.w3.org/2002/07/owl#" >
   <!ENTITY xsd  "http://www.w3.org/2001/XMLSchema#" >
]>
<rdf:RDF
   xmlns     = "http://example.com/store#"
   xmlns:store = "http://example.com/store#"
   xml:base  = "http://example.com/store#"
   xmlns:owl = "http://www.w3.org/2002/07/owl#"
   xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:rdfs= "http://www.w3.org/2000/01/rdf-schema#"
>

<owl:Ontology rdf:about="">
   <rdfs:comment>
      An example OWL ontology for Online Bookstores (The Ultimate   
      Mashup: Part #4)
   </rdfs:comment>
   <rdfs:label>BookStore Ontology</rdfs:label>
</owl:Ontology>
  
</rdf:RDF>

Ở trên đầu tài liệu, bạn xác định các thực thể XML cho mỗi xâu miền không gian tên XML của mình. Các thực thể này cho phép bạn dễ dàng thêm vào miền không gian tên khi cần thiết. Ví dụ, bạn có thể sử dụng thực thể &xsd; để viết tắt các miền không gian tên nếu bạn đã xác định lược đồ XML định nghĩa các kiểu dữ liệu.

Tiếp theo là bản thân thành phần RDF, với tất cả các điều kiện về miền không gian tên được xác định. Các thành phần này chứa phần tử owl:Ontology.

Trước khi đi tiếp, hãy xem điều này có nghĩa là gì. Nó có nghĩa là ở nơi nào đó trong owl: namespace (http://www.w3.org/2002/07/owl#) là một định nghĩa về một lớp đã gọi Ontology. Định nghĩa này cho phép bạn tạo một đối tượng Ontology riêng. Bởi vì nó là yếu tố chính, nó không phải tham chiếu đến bất kỳ các tài nguyên khác.

Một khi bạn tạo nó, bạn có thể sử dụng các thuộc tính chú thích (comment) và nhãn (label) của các RDF để thêm thông tin vào bản thân Ontology.

Các lớp OWL cơ bản nhất

Ở phần thảo luận về RDF, bạn đã học cách bạn có thể xác định một tài nguyên khi có kiểu rdf:Class, hoặc một loại lớp cụ thể, sau đó bạn có thể sử dụng chúng như một kiểu. Bạn đã học vậy bạn có thể tạo các subclass của các kiểu cá thể này.

Trong OWL, một cách tự động mọi lớp là một lớp con của owl:Thing. (Bởi vì nếu nó không là một "thing", bạn sẽ không cần một lớp cho nó.) Điều đó có nghĩa là bạn không phải xác định mối quan hệ một cách rõ ràng bởi đó là giả thiết.

Cơ bản về owl:Thing là một lớp cơ sở mà mọi thứ khác được lấy từ đó và bạn sẽ được sử dụng tốt.

OWL cũng xác định một lớp thứ hai, owl:Nothing. Lớp này biểu diễn một lớp rỗng, không có thành phần nào cả.

Tạo các lớp

Bây giờ bạn biết nền tảng cơ bản như thế nào, bạn có thể bắt đầu tạo các lớp OWL cho riêng mình (xem ví dụ 4).

Ví dụ 4. Tạo các class
...
<owl:Ontology rdf:about="">
   <rdfs:comment>
      An example OWL ontology for Online Bookstores (The Ultimate   
      Mashup: Part #4)
   </rdfs:comment>
   <rdfs:label>BookStore Ontology</rdfs:label>
</owl:Ontology>
  
<owl:Class rdf:ID="Service">
   <rdfs:label>Web Service</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="Store">
   <rdfs:label>Online Store</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="Bookstore">
   <rdfs:label>Bookstore</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="Product">
   <rdfs:label>Product sold at online store</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="Book">
   <rdfs:label>Book</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="Movie">
   <rdfs:label>Movie</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="Person">
   <rdfs:label>Person</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="Author">
   <rdfs:label>Author</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="Director">
   <rdfs:label>Director</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="BookGenre">
   <rdfs:label>Book Genre</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="StockItem">
   <rdfs:label>Stocked Item</rdfs:label>
</owl:Class>

</rdf:RDF>

Bạn đã làm gì ở đây, bạn đã tạo một thể hiện của owl:Class với mọi thực thể mà bạn muốn liên kết với bản thể luận của mình. Bằng việc gán cho mỗi chúng một rdf:ID, bạn có thể dễ dàng tham chiếu lại chúng từ các định danh sau.

Các lớp con OWL

Bây giờ bạn đã có các lớp, bạn có thể bắt đầu tạo các quan hệ giữa chúng (xem ví dụ 5).

Ví dụ 5. Tạo các lớp con subclass
...
<owl:Class rdf:ID="Service">
   <rdfs:label>Web Service</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="Store">
   <rdfs:subClassOf rdf:resource="#Service"/>
   <rdfs:label>Online Store</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="Bookstore">
   <rdfs:subClassOf rdf:resource="#Store"/>
   <rdfs:label>Bookstore</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="Product">
   <rdfs:label>Product sold at online store</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="Book">
   <rdfs:subClassOf rdf:resource="#Product"/>
   <rdfs:label>Book</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="Movie">
   <rdfs:subClassOf rdf:resource="#Product"/>
   <rdfs:label>Movie</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="Person">
   <rdfs:label>Person</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="Author">
   <rdfs:subClassOf rdf:resource="#Person"/>
   <rdfs:label>Author</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="Director">
   <rdfs:subClassOf rdf:resource="#Person"/>
   <rdfs:label>Director</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="BookGenre">
</owl:Class>

<owl:Class rdf:ID="StockItem">
</owl:Class>

</rdf:RDF>

Không có gì huyền bí ở đây; bạn chỉ sử dụng cùng một thuộc tính rdfs:subClassOf bạn đã học ở phần 4 để tạo các quan hệ giữa các kiểu mà bạn đang tạo ra.

DatatypePropertyObjectProperty

Một khi bạn tạo các lớp, bạn cần phải thêm các thuộc tính. Trong OWL, trái với RDF và RDFs bạn có hai kiểu thuộc tính: DatatypePropertyObjectProperty. DatatypeProperty xác định một thuộc tính có một kiểu đơn giản như là một giá trị (xem ví dụ 6).

Ví dụ 6. DatatypeProperty
...
<owl:Class rdf:ID="Service">
   <rdfs:label>Web Service</rdfs:label>
</owl:Class>
<owl:DatatypeProperty  rdf:ID="endpoint">
   <rdfs:domain rdf:resource="#Service"/>
   <rdfs:range rdf:resource="&xsd;anyURI"/>
</owl:DatatypeProperty>

...

<owl:Class rdf:ID="Book">
   <rdfs:subClassOf rdf:resource="#Product"/>
   <rdfs:label>Book</rdfs:label>
</owl:Class>
<owl:DatatypeProperty rdf:ID="title"> 
  <rdfs:domain rdf:resource="#Book"/>
  <rdfs:range rdf:resource="&xsd;string"/>
</owl:DatatypeProperty>

<owl:Class rdf:ID="Movie">
   <rdfs:subClassOf rdf:resource="#Product"/>
   <rdfs:label>Movie</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="Person">
   <rdfs:label>Person</rdfs:label>
</owl:Class>
<owl:DatatypeProperty rdf:ID="name"> 
  <rdfs:domain rdf:resource="#Person"/>
  <rdfs:range rdf:resource="&xsd;string"/> 
</owl:DatatypeProperty>

...

<owl:Class rdf:ID="StockItem">
</owl:Class>
<owl:DatatypeProperty rdf:ID="itemPrice"> 
  <rdfs:domain rdf:resource="#StockItem"/>
  <rdfs:range rdf:resource="&xsd;double"/> 
</owl:DatatypeProperty>

</rdf:RDF>

Ở đây bạn tạo bốn thuộc tính đơn giản, mỗi thuộc tính được gán vào một trong các lớp của bạn và xác định cụ thể với một kiểu lược đồ XML đã xác định.

Mặt khác ObjectProperty có các cá thể các đối tượng của một lớp riêng như là giá trị của nó (xem ví dụ 7).

Ví dụ 7. ObjectProperty
...
<owl:Class rdf:ID="Author">
   <rdfs:subClassOf rdf:resource="#Person"/>
   <rdfs:label>Author</rdfs:label>
</owl:Class>
<owl:ObjectProperty rdf:ID="writtenBy"> 
  <rdfs:domain rdf:resource="#Book"/>
  <rdfs:range rdf:resource="#Author"/> 
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="writerOf">
  <rdfs:domain rdf:resource="#Author"/>
  <rdfs:range rdf:resource="#Book"/> 
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="genreOf">
  <rdfs:domain rdf:resource="#Book"/>
  <rdfs:range rdf:resource="#BookGenre"/> 
</owl:ObjectProperty>

...

<owl:Class rdf:ID="StockItem">
</owl:Class>
<owl:DatatypeProperty rdf:ID="itemPrice"> 
  <rdfs:domain rdf:resource="#StockItem"/>
  <rdfs:range rdf:resource="&xsd;double"/> 
</owl:DatatypeProperty>

<owl:ObjectProperty  rdf:ID="stockedProduct">
   <rdfs:domain rdf:resource="#StockItem"/>
   <rdfs:range rdf:resource="#Product"/>
</owl:ObjectProperty>
<owl:ObjectProperty  rdf:ID="stocks">
   <rdfs:domain rdf:resource="#Store"/>
   <rdfs:range rdf:resource="#StockItem"/>
</owl:ObjectProperty>

</rdf:RDF>

Chú ý rằng các thuộc tính này tham chiếu trở lại các lớp xác định với miền giá trị của chúng (các lớp ở chỗ mà chúng có thể xuất hiện) và phạm vi của chúng (các kiểu giá trị mà chúng có thể giữ).

Bản thể luận hợp lệ

Vào lúc này, bạn đã đi khá xa mà không làm bất cứ điều gì với XML, vì vậy có lẽ bạn nên chạy nó qua một vài trật tự hợp lệ để chắc chắn rằng bạn không có bất kỳ lỗi nào. Bạn có thể làm điều đó sử dụng bất kì OWL reasoner. May thay, Mindswap tạo một công cụ hợp lệ sẵn có trực tuyến (xem Tài nguyên). Để sử dụng nó, chỉ cần sao chép và dán bản thể luận vào một hộp văn bản và chọn các tùy chọn thích hợp. Chúng ta sử dụng mọi thứ trừ "Enable processing E-connected ontologies" (khi chúng ta không sử dụng một bản thể luận E-connected).

Khi bạn nhấn Submit, bạn sẽ xem một phân tích của bản thể luận giống như trong Hình 3.

Hình 3. Phân tích của bản thể luận
Phân tích của bản thể luận

Các công cụ hiển thị một loạt dữ liệu về bản thể luận. Trong trường hợp của mình, bạn quan tâm hai điều: cây biểu diễn sự phân cấp của các lớp của bạn và thực tế là không có lỗi nào.

Công cụ này cũng sẽ hiển thị bất kì sự xây dựng nào mà sẽ di chuyển một bản thể luận ra khỏi lĩnh vực OWL rút gọn hoặc OWL DL cũng như bất kì thể hiện nào cho một lớp riêng.

Tạo các thể hiện

Các thể hiện đơn giản là để tạo ra. Thực tế, bạn tạo chúng tương tự như cách mà bạn đã làm trong RDF (xem ví dụ 8).

Ví dụ 8. Tạo các thể hiện
...
<owl:ObjectProperty  rdf:ID="stocks">
   <rdfs:domain rdf:resource="#Store"/>
   <rdfs:range rdf:resource="#StockItem"/>
</owl:ObjectProperty>

<Bookstore rdf:ID="Amazon.com">
   <endpoint>
      http://soap.amazon.com/onca/soap?Service=AWSECommerceService
   </endpoint>
</Bookstore>
<Bookstore rdf:ID="BarnesAndNoble.com">
   <endpoint>
      http://services.xmethods.net:80/soap/servlet/rpcrouter
   </endpoint>
</Bookstore>

<BookGenre rdf:ID="Fiction"/>

<Author rdf:ID="J_K_Rowling"/>
<Author rdf:ID="Fyodor_Dostoevsky"/>

<Book rdf:ID="Harry_Potter_and_the_Sorcerers_Stone">
   <writtenBy rdf:resource="#J_K_Rowling"/>
</Book>
<Book rdf:ID="Crime_and_Punishment">
   <writtenBy rdf:resource="#Fyodor_Dostoevsky"/>
</Book>

</rdf:RDF>

Chú ý rằng bạn đã tạo vài cá thể và các thuộc tính được gán -- nhưng không phải là tất cả các thuộc tính. Ví dụ, trong khi bạn đã xác định một Book với một ID của Harry_Potter_and_the_Sorcerers_Stone và chỉ ra rằng nó writtenBy (được viết bởi) J_K_Row/ling, bạn không cần đề cập đến J_K_RowlingwriterOf Harry_Potter_and_the_Sorcerers_Stone. Tại sao? Bởi vì bạn không phải làm thế. Một trong những lợi thế của OWL là bạn có thể tạo một bản thể luận với đầy đủ thông tin cho hệ thống tính toán theo cách của nó.

Nhưng trước tiên bạn xem thêm một vài trí tuệ cơ bản bạn có thể xây dựng vào một bản thể luận


Chi tiết hơn

Một trong những cách bạn có thể xây dựng trí tuệ vào một bản thể luận là đưa đặc trưng về thông tin bạn mong chờ.

Yêu cầu một giá trị cụ thể

Một cách cụ thể vào bản thể luận của bạn là đặt các hạn chế trên một lớp, như trong hình 9.

Hình 9. Yêu cầu một giá trị cụ thể
...
<owl:Class rdf:ID="BookGenre">
</owl:Class>

<owl:ObjectProperty rdf:ID="genreOf">
  <rdfs:domain rdf:resource="#Book"/>
  <rdfs:range rdf:resource="#BookGenre"/> 
</owl:ObjectProperty>

<owl:Class rdf:ID="FictionBook">
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="#genreOf" />
       <owl:hasValue rdf:resource="#Fiction" />
     </owl:Restriction>
   </rdfs:subClassOf>
</owl:Class>

<owl:Class rdf:ID="Director">
   <rdfs:subClassOf rdf:resource="#Person"/>
   <rdfs:label>Director</rdfs:label>
</owl:Class>
...

Những gì bạn đã làm ở đây là tạo một lớp FictionBook, đó là một lớp con của một lớp khác. Tuy nhiên, lớp đó không có tên; bạn đang xác định nó bên trong một lớp có một giới hạn trên thuộc tính genreOf của nó. Giới hạn đó nói rằng thuộc tính genreOf phải có cá thể Fiction như là một giá trị của nó.

Vì vậy hãy nhìn vào những gì bạn đang thực sự nói đến. Bạn đang nói rằng để được xem là một thành viên của lớp FictionBook, một cá thể phải có một genreOf của #Fiction. Chú ý rằng bạn không nói là nếu một cá thể có một genreOf của #Fiction thì nó là thành viên của lớp FictionBook một cách tự động. Cách này đã chỉ rõ, một cá thể có thể có một genreOf của #Fiction, nhưng không là FictionBook. (Có lẽ đó là một FictionMovie.)

Yêu cầu một số tối thiểu các giá trị

Một hạn chế ít nghiêm ngặt hơn là chỉ ra một số các giá trị một cá thể phải có. Ví dụ, bạn có thể chỉ rõ rằng một Book phải có ít nhất một tác giả (Author) (xem ví dụ 10).

Ví dụ 10. Yêu cầu một số tối thiểu các giá trị
...
<owl:Class rdf:ID="Product">
   <rdfs:label>Product sold at online store</rdfs:label>
</owl:Class>

<owl:Class rdf:ID="Book">
   <rdfs:subClassOf rdf:resource="#Product"/>
   <rdfs:label>Book</rdfs:label>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="#writtenBy" />
       <owl:minCardinality rdf:datatype=
            "&xsd;nonNegativeInteger">1</owl:minCardinality>
     </owl:Restriction>
   </rdfs:subClassOf>
</owl:Class>

...

<owl:Class rdf:ID="Author">
   <rdfs:subClassOf rdf:resource="#Person"/>
   <rdfs:label>Author</rdfs:label>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="#writerOf" />
       <owl:minCardinality rdf:datatype=
          "&xsd;nonNegativeInteger">1</owl:minCardinality>
     </owl:Restriction>
   </rdfs:subClassOf>
</owl:Class>

<owl:ObjectProperty rdf:ID="writtenBy"> 
   <rdfs:domain rdf:resource="#Book"/>
   <rdfs:range rdf:resource="#Author"/> 
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="writerOf">
</owl:ObjectProperty>
...

Bạn cũng đã chỉ ra rằng để là một Author, một Person phải là tác giả writerOf của ít nhất một Book.

Bạn cũng có thể sử dụng thuộc tính maxCardinality để xác định số tối thiểu các giá trị mà một thuộc tính có thể nhận. Nhưng thiết lập điều đó cho thuộc tính writtenBy của chúng ta phải thực hiện, thật là khó để ghi vào danh sách bài tập sách lập trình của ngày hôm nay!

Giới hạn một nhóm các giá trị

Trước khi chúng ta chuyển đến khả năng suy diễn, hãy xem thêm về việc hạn chế các giá trị.

Điều gì xảy ra nếu bạn muốn chỉ rõ một nhóm các giá trị cho phép. Ví dụ, giả sử bạn có một danh sách các thể loại sách cụ thể, và chúng chỉ là những thể loại được phép? Bạn có thể tạo ra một lớp giống như thế này (xem ví dụ 11).

Ví dụ 11. Tạo một danh sách cụ thể
...
<owl:Class rdf:ID="BookGenre">
   <rdfs:subClassOf>
     <owl:AllDifferent rdf:ID="GenreList">
      <owl:distinctMembers rdf:parseType="Collection">
        <owl:Thing rdf:ID="Fiction" />
        <owl:Thing rdf:ID="Nonfiction" />
        <owl:Thing rdf:ID="History" />
        <owl:Thing rdf:ID="Philosophy" />
        <owl:Thing rdf:ID="Memoir" />
      </owl:distinctMembers>
     </owl:AllDifferent>
   </rdfs:subClassOf>
</owl:Class>
...

Bây giờ, bạn đã thay đổi lớp BookGenre để nó chứa một trong năm đối tượng. Chúng gọi là Fiction, Nonfiction, History, Philosophy, và Memoir. Nhưng bạn đã làm nhiều hơn những điều chỉ cần đó.

Trước hết, bằng việc sử dụng các lớp AllDifferentdistinctMembers bạn chỉ ra rằng mỗi Book có thể thuộc vào chỉ một trong những thể loại này. Vì vậy một Book không thể là FictionMemoir không có gì mới nhất là điên rồ cả. Nó phải là một cái này hoặc cái khác. Ngoài ra, bằng việc xác định parseType như là Collection, bạn làm cho nó không thể thêm vào các thành phần bổ sung vào lớp này trên các định danh khác.

Bây giờ bạn có thể chuyển đến tất cả các dữ liệu này gì có thể nói gián tiếp cho bạn.


Thêm vào khả năng suy diễn

Tất cả những thứ này là tốt rồi, nhưng có một điều là con người có thể suy luận còn một máy tính thì không thể. Ví dụ, nếu một cuốn sách được viết bởi ("written by") J.K. Rowling thì J.K. Rowling phải là tác giả ("writer of") của cuốn sách đó. Nhưng không có gì trong bản thể luận nói về điều đó. Hãy xem một vài cách mà OWL cho phép loại suy luận đó.

Các thuộc tính bắc cầu

Một trong những khái niệm đơn giản nhất để nắm bắt đó là thuộc tính bắc cầu. Nói cách khác, nếu đảo Staten là một phần của thành phố New York, và thành phố New York là một phần của bang New York thì đảo Staten phải là một bộ phận của bang New York đúng không? Chắc chắn rồi, nhưng bạn phải tạo mối quan hệ đó trong bản thể luận một cách rõ ràng. Ví dụ, bạn có thể ánh xạ các phân loại như biểu diễn trong ví dụ 12.

Ví dụ 12. Các loại ngoại lệ
...
<owl:ObjectProperty  rdf:ID="stocks">
  <rdfs:domain rdf:resource="#Store"/>
  <rdfs:range rdf:resource="#StockItem"/>
</owl:ObjectProperty>

<owl:Class rdf:ID="ProductCategory" />
<owl:TransitiveProperty rdf:ID="isSubcategoryOf"> 
  <rdfs:domain rdf:resource="#ProductCategory"/>
  <rdfs:range rdf:resource="#ProductCategory"/> 
</owl:TransitiveProperty>

<ProductCategory rdf:ID="Books"/>
<ProductCategory rdf:ID="Arts_and_Entertainment">
  <isSubcategoryOf rdf:resource="#Books" />
</ProductCategory>
<ProductCategory rdf:ID="Comics_and_Graphic_Novels">
  <isSubcategoryOf rdf:resource="#Arts_and_Entertainment" /> 
</ProductCategory>

<Bookstore rdf:ID="Amazon.com"/>
...

Trước tiên tạo một lớp ProductCategory, và cho nó một thuộc tính isSubcategoryOf. Bạn có thể xác định nó là một Property với một kiểu của TransitiveProperty nhưng cú pháp này cẩn thận với điều đó.

Cơ bản bạn đã nói rằng vì loại Comics_and_Graphic_Novels là một loại con (subcategory) của Arts_and_Entertainment, và Arts_and_Entertainment là một loại con của Books thì Comics_and_Graphic_Novels là một loại con của Books. Bằng cách này, bạn đưa ra một khái niệm rõ ràng nhất của bộ não con người (trưởng thành) và đưa nó vào một khía cạnh mà phần mềm có thể hiểu được.

OWL cho phép bạn làm tương tự với các khái niệm khác của con người.

Các thuộc tính đối xứng (Symmetric properties)

Một khái niệm khác rõ ràng với một người nhưng không nhất thiết phải rõ ràng với máy tính, đó là một thuộc tính đối xứng. Ví dụ, nếu Harry Potter and the Sorcerer's Stone là một bộ với Crime and Punishment thì nó có lí do để Crime and Punishment là một bộ với Harry Potter and the Sorcerer's Stone nhưng chỉ khi bạn xác định các thuộc tính theo cách đó. (xem ví dụ 13).

Ví dụ 13. Các thuộc tính đối xứng
...
     </owl:AllDifferent>
   </rdfs:subClassOf>
</owl:Class>

<owl:SymmetricProperty rdf:ID="bundledWith">
  <rdfs:domain rdf:resource="#Product"/>
  <rdfs:range rdf:resource="#Product"/> 
</owl:SymmetricProperty>

<owl:Class rdf:ID="StockItem">
...

Ưu điểm của các thuộc tính đang định nghĩa theo cách này là khả năng thực hiện các suy luận. Ví dụ, bạn có thể tạo các cá thể, như trình bày trong ví dụ 14.

Ví dụ 14. Các cá thể và các thuộc tính đối xứng
...
<Book rdf:ID="Harry_Potter_and_the_Sorcerers_Stone">
   <writtenBy rdf:resource="#J_K_Rowling"/>
   <genreOf rdf:resource="#Fiction"/>
</Book>
<Book rdf:ID="Crime_and_Punishment">
   <writtenBy rdf:resource="#Fyodor_Dostoevsky"/>
      <bundledWith rdf:resource= "#Harry_Potter_and_the_Sorcerers_Stone"/>
</Book>
...

Mặc dù bạn đã nói không có vấn đề gì về việc xây dựng tài nguyên #Harry_Potter_and_the_Sorcerers_Stone hệ thống biết rằng bundledWith #Crime_and_Punishment được dựa trên thuộc tính đối xứng.

Một thuộc tính khác làm việc tốt với con người nhưng lại không tốt đối với các máy tính đó là thuộc tính nghịch đảo.

Các thuộc tính nghịch đảo

Các thuộc tính nghịch đảo là các thuộc tính mà trong đó, như các nhà vật lí nói, với mỗi một hoạt động thì có một hoạt động tương ứng nhưng ngược lại. Ví dụ, nếu Harry_Potter_and_the_Sorcerers_Stone được viết bởi (writtenBy J_K_Rowling) thì ngay lập tức con người suy luận ra rằng J_K_Rowling là tác giả của (Harry_Potter_and_the_Sorcerers_Stone) nhưng máy tính thì không như vậy, trừ khi bạn chỉ cho nó một cách trực tiếp. (xem ví dụ 15).

Ví dụ 15. Các thuộc tính nghịch đảo
...
<owl:Class rdf:ID="Author">
   <rdfs:subClassOf rdf:resource="#Person"/>
   <rdfs:label>Author</rdfs:label>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="#writerOf" />
       <owl:minCardinality
 rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality>
     </owl:Restriction>
   </rdfs:subClassOf>
</owl:Class>

<owl:ObjectProperty rdf:ID="writtenBy"> 
  <rdfs:domain rdf:resource="#Book"/>
  <rdfs:range rdf:resource="#Author"/> 
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="writerOf">
  <owl:inverseOf rdf:resource="#writtenBy"/>
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="genreOf">
  <rdfs:domain rdf:resource="#Book"/>
  <rdfs:range rdf:resource="#BookGenre"/> 
</owl:ObjectProperty>
...

Ở đây bạn tạo thuộc tính writerOf như bình thường, ngay cả việc đặt một hạn chế trên nó với lớp Author. Bằng việc thêm vào nó một thuộc tính inverseOf bạn có thể liên kết các thuộc tính writerOfwrittenBy lại với nhau. Chú ý rằng, có vài xây dựng trí tuệ ở đây; bạn không phải chỉ rõ writtenBy như là một thuộc tính nghịch đảo inverseOf của thuộc tính writerOf. Chỉ một hướng là đủ.

Các thuộc tính chức năng nghịch đảo (InverseFunctional)

Một khái niệm mà chúng ta thường xuyên liên quan đến trong các ứng dụng là Khóa chính (primary key) của một phân loại. Đó là giá trị xác định duy nhất một cá thể. Ví dụ, như bình thường, một người chỉ có thể có duy nhất một số an ninh xã hội (Social Security Number). Trong các nhóm OWL, thực hiện số an ninh xã hội là một thuộc tính chức năng. Nếu bạn có hai tập dữ liệu liên quan đến cùng một người, thì bạn có thể dán nhãn họ cùng một số an ninh xã hội. Nhưng OWL cũng cho chúng ta loại thuộc tính mạnh hơn một chút đó là thuộc tính chức năng nghịch đảo (inverse functional). Một thuộc tính inverse functional có thể được sử dụng để nhận dạng các cá nhân. Ví dụ, nếu bạn có hai tập dữ liệu được liệt kê theo cùng số an ninh xã hội thì bạn biết rằng chúng liên quan đến cùng một người.

Trong các cơ sở dữ liệu lớn, đây hầu như là một khái niệm làm khiếp sợ nhưng thuộc tính InverseFunctionalProperty không cho phép kết hợp dữ liệu dễ dàng. Đưa các điều này vào bản thể luận của bạn, bạn có thể xác định số ISBN cho một thuộc tính InverseFunctionalProperty (xem ví dụ 16).

Ví dụ 16. Xác định một InverseFunctionalProperty
...
<owl:DatatypeProperty rdf:ID="title"> 
  <rdfs:domain rdf:resource="#Book"/>
  <rdfs:range rdf:resource="&xsd;string"/> 
</owl:DatatypeProperty>

<owl:Class rdf:ID="ISBN">
</owl:Class>
<owl:InverseFunctionalProperty  rdf:ID="isbn">
   <rdfs:domain rdf:resource="#ISBN"/>
   <rdfs:range rdf:resource="#Book"/>
</owl:InverseFunctionalProperty>

<owl:Class rdf:ID="Movie">
   <rdfs:subClassOf rdf:resource="#Product"/>
   <rdfs:label>Movie</rdfs:label>
</owl:Class>
...

Điều này có nghĩa là gì, nếu bạn chọn dữ liệu về cùng một cuốn sách từ hai dịch vụ web khác nhau, bạn có thể liên kết dữ liệu đó với nhau bằng cách sử dụng thuộc tính isbn, nó cho phép bạn cung cấp thông tin cho người dùng nhiều hơn là bạn có thể từ chỉ một dịch vụ web.

Các lớp tương đương (Equivalent classes)

Trong khi chúng ta đang bàn về chủ đề nhiều dịch vụ web mà lại nói nhiều về các bản thể luận. Trong một vài trường hợp, bạn sẽ cần nói cho hệ thống biết rằng một lớp đơn có thể được gọi tắt bằng các tên gọi khác nhau. Ví dụ, bạn có thể có một dịch vụ gọi là một Person. Người mà viết (writerOf) một cuốn sách là tác giả (Author) và cách gọi khác nhau của cùng một PersonWriter. Bạn có thể nói cho hệ thống rằng các khái niệm đó là giống nhau bằng cách sử dụng thuộc tính equivalentClass (xem ví dụ 17).

Ví dụ 17. Các lớp tương đương
...
<owl:Class rdf:ID="Author">
   <rdfs:subClassOf rdf:resource="#Person"/>
   <rdfs:label>Author</rdfs:label>
   <rdfs:subClassOf>
     <owl:Restriction>
       <owl:onProperty rdf:resource="#writerOf" />
       <owl:minCardinality rdf:datatype=
            "&xsd;nonNegativeInteger">1</owl:minCardinality>
     </owl:Restriction>
   </rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="Writer"> <owl:equivalentClass rdf:resource=
"#Author"/> </owl:Class>

...

<owl:Class rdf:ID="FictionBook">
   <owl:equivalentClass>
     <owl:Restriction>
       <owl:onProperty rdf:resource="#genreOf" />
    <owl:hasValue rdf:resource="#Fiction" />
     </owl:Restriction>
   </owl:equivalentClass>
</owl:Class>
...

Chú ý rằng bạn sử dụng equivalentClass vào hai trường hợp khác nhau ở đây. Thứ nhất là để chỉ rõ hai lớp là tương đương. Điều đó khá là đơn giản. Nhưng trường hợp thứ hai không đơn giản như vậy. Trước đó, bạn đã tạo một lớp FictionBook bằng việc chỉ ra nó là lớp con có chứa các Books với một genreOf Fiction. Nói cách khác, để là một FictionBook, thì một Book phải là một genreOf Fiction.

Điều đó không có nghĩa là nếu nó là một Book với một genreOf Fiction. subClassOf tạo nên các lá mở ra khả năng có các cuốn sách Books với một genreOf Fiction không phải là FictionBooks. Bằng việc khai báo lớp thay vì sử dụng equivalentClass, bạn chỉ rõ lớp FictionBook và lớp kết quả trả về từ tất cả các hạn chế là tương đương. Do đó, bằng định nghĩa nếu đó là một Book với một genreOf Fiction thì đó là một FictionBook, đó là những gì mà bộ não của bạn cho bạn biết trước tiên.

Các thuộc tính tương đương (Equivalent properties)

Bạn có thể thực hiện khéo léo bằng tay với các thuộc tính. (xem ví dụ 18).

Ví dụ 18. Các thuộc tính tương đương (Equivalent properties)
...
<owl:ObjectProperty rdf:ID="writtenBy"> 
  <rdfs:domain rdf:resource="#Book"/>
  <rdfs:range rdf:resource="#Author"/> 
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="writerOf">
  <owl:inverseOf rdf:resource="#writtenBy"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="authorOf">
  <owl:equivalentProperty rdf:resource="#writerOf"/>
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="genreOf">
  <rdfs:domain rdf:resource="#Book"/>
  <rdfs:range rdf:resource="#BookGenre"/> 
</owl:ObjectProperty>
...

Trong trường hợp này bạn cho hệ thống biết rằng các thuộc tính authorOfwriterOf chỉ cùng một khái niệm.

Nhưng còn các cá nhân? Làm thế nào để bạn có thể chỉ rõ chúng là tương đương?

Các tài nguyên giống hệt nhau (Identical resources)

Một tình huống khác là có thể chia cắt quá trình xử lí dữ liệu từ nhiều dịch vụ web là các cá nhân tương đương. Ví dụ, một dịch vụ có thể cung cấp cho bạn một Authorof J_K_Rowling, trong khi dịch vụ khác lại định nghĩa Joanne_Rowling (xem ví dụ 19).

Ví dụ 19. Các tài nguyên giống hệt nhau
...
<Author rdf:ID="J_K_Rowling"/>
<Author rdf:ID="Joanne_Rowling"> <owl:sameAs rdf:resource="#J_K_Rowling" 
/> </Author>

<Author rdf:ID="Fyodor_Dostoevsky"/>
...

Bằng cách này, bạn có thể nói cho hệ thống biết rằng bất kì điều gì nó biết về J_K_Rowling cũng áp dụng cho Joanne_Rowling, và ngược lại.


Làm rõ một chút: Các đặc tính OWL

Tất cả thời điểm này, bạn xây dựng bản thể luận của mình mà không suy nghĩ về các kiểu hoặc mức phù hợp với bản thể luận của mình. Một bản thể luận OWL đầy đủ hợp lệ là gì. Xem điều gì là cần thiết để đi xuống mức độ một hoặc hai.

OWL đầy đủ

Trước tiên các định nghĩa dừng lại ở bản thể luận của bạn vào một loại OWL đầy đủ. Trong trường hợp của bạn nó chỉ là một, định nghĩa BookGenre (xem ví dụ 20).

Ví dụ 20. Định nghĩa BookGenre
...
<owl:Class rdf:ID="BookGenre">
   <rdfs:subClassOf>
     <owl:AllDifferent rdf:ID="GenreList">
      <owl:distinctMembers rdf:parseType="Collection">
        <owl:Thing rdf:ID="Fiction" />
        <owl:Thing rdf:ID="Nonfiction" />
        <owl:Thing rdf:ID="History" />
        <owl:Thing rdf:ID="Philosophy" />
        <owl:Thing rdf:ID="Memoir" />
      </owl:distinctMembers>
     </owl:AllDifferent>
   </rdfs:subClassOf>
</owl:Class>
...

Định nghĩa này đưa bản thể luận ra khỏi lĩnh vực của OWL DL. Nó định nghĩa GenreList "ngay trong khi hoạt động" để nói rằng, thay vì định nghĩa nó một cách riêng biệt, thì ta chỉ dẫn đến nó.

OWL DL

Bạn có thể sửa vấn đề này bằng việc xác định lớp GenreList một cách riêng rẽ. (xem ví dụ 21).

Ví dụ 21. Di chuyển tới OWL DL
...
<owl:Class rdf:ID="GenreList" />
<owl:Class rdf:ID="Genre" />
<Genre rdf:ID="Fiction"/>
<Genre rdf:ID="Nonfiction"/>
<Genre rdf:ID="History"/>
<Genre rdf:ID="Philosophy"/>
<Genre rdf:ID="Memoir"/>

<owl:Class rdf:ID="BookGenre">
   <rdfs:subClassOf>
     <owl:AllDifferent rdf:about="#GenreList">
      <owl:distinctMembers rdf:parseType="Collection">
        <Genre rdf:about="#Fiction" />
        <Genre rdf:about="#Nonfiction" />
        <Genre rdf:about="#History" />
        <Genre rdf:about="#Philosophy" />
        <Genre rdf:about="#Memoir" /> 
      </owl:distinctMembers>
     </owl:AllDifferent>
   </rdfs:subClassOf>
</owl:Class>
...

Ngoài ra để định nghĩa lớp GenreList một cách riêng biệt và tham chiếu tới chúng, bạn có thể làm rõ lên distinctMembers để chỉ ra rằng chúng phải là các đối tượng Genre và tham chiếu các tài nguyên cụ thể hơn là tạo ra các tài nguyên "Thing" chung chung "ngay trong khi hoạt động".

OWL rút gọn

Một mức OWL rút gọn là hạn chế nhiều hơn, nhưng vẫn khá diễn cảm. Ví dụ, tất cả những gì bạn làm trong việc tạo ra bản thể luận này là hợp pháp với OWL rút gọn -- ngoại trừ với một định nghĩa (xem ví dụ 22).

Ví dụ 22. Một định nghĩa OWL rút gọn không hợp lệ
...
<owl:Class rdf:ID="FictionBook">
   <owl:equivalentClass>
     <owl:Restriction>
       <owl:onProperty rdf:resource="#genreOf" />
       <owl:hasValue rdf:resource="#Fiction" />
     </owl:Restriction>
   </owl:equivalentClass>
</owl:Class>
...

Đó không phải là vấn đề bạn đặt một hạn chế trên thuộc tính genreOf, mà vấn đề là kiểu hạn chế mà bạn đặt. OWL Lite cho phép các hạn chế dựa trên số lượng các yếu tố của một tập -- nghĩa là một số tối thiểu hoặc tối đa các giá trị -- nhưng không hạn chế với việc xác định các giá trị đó phải là gì.

Khác hơn thế, mọi thứ bạn đặt vào bản thể luận là hợp lệ với OWL rút gọn. Nếu bạn gỡ bỏ một trong những định nghĩa này bạn sẽ có một bản thể luận OWL rút gọn.


OWL và các dịch vụ Web

Hiện nay bạn đã xử lý với nhiều khái niệm bản thể luận và định nghĩa dữ liệu. Nhưng bạn có thể liên hệ điều này với một dịch vụ Web như thế nào? Một trong những cách tiềm năng là sử dụng OWL-S. Bạn không đi quá sâu vào các chi tiết sử dụng của nó nhưng nó có ích với ý tưởng là điều gì đó giống như thế có thể làm việc được như thế nào.

OWL-S là một OWL dựa trên dịch vụ bản thể luận web. Nó thiết lập Services được tạo ra từ các hồ sơ Profiles, Các mô hình Models (hoặc các tiến trình -Processes), và Groundings. Một Service cho phép bạn chỉ rõ dịch vụ web trong các nhóm URIs và các tham số riêng của nó, thông tin trong bản thể luận OWL của riêng bạn, bạn muốn ánh xạ và các phần tử dịch vụ web và phương pháp ánh xạ để chuyển thông tin bản thể luận của bạn tới đầu vào dịch vụ web và sau đó chuyển đầu ra dịch vụ web trở lại thành phần bản thể luận của bạn.

Service

Ví dụ, nếu bạn dùng dịch vụ Amazon's E-commerce thì bạn có thể biểu diễn trong OWL-S như sau (xem ví dụ 23).

Ví dụ 23. Dịch vụ Amazon.com's E-commerce trong OWL-S
<service:Service rdf:ID="AmazonBookFinderService">
   <service:presents rdf:resource="#AmazonBookFinderProfile"/>
   <service:describedBy rdf:resource="#AmazonBookFinderProcess"/>
   <service:supports rdf:resource="#AmazonBookFinderGrounding"/>
</service:Service>

Service biểu diễn một Profile, nó nói cho bạn biết rằng Service làm gì ở mức trừu tượng.

Profile

Một Profile chủ yếu là bản mô tả. Một cấu hình chứa thông tin về tên và mô tả của một dịch vụ cũng như xác định các tham số vào ra cho dịch vụ (xem ví dụ 24).

Ví dụ 24. Profile
<profile:Profile rdf:ID="AmazonBookFinderProfile">
   <service:presentedBy rdf:resource="#AmazonBookFinderService"/>
   <profile:serviceName xml:lang="en">Amazon Book 
                                   Finder</profile:serviceName>
   <profile:textDescription xml:lang="en">This service returns 
          the information of a book whose title best matches the 
          given string, from the Amazon E-Commerce 
          Service.</profile:textDescription>

   <profile:hasInput rdf:resource="#BookName"/>
   <profile:hasOutput rdf:resource="#ItemInfo"/>
</profile:Profile>

Một Service được miêu tả bởi một Model, nó cũng đưa ra cấu trúc của vài loại Process.

Process

Tiến trình Process có thể là rất đơn giản (có nghĩa là một AtomicProcess thực thi chỉ một giao dịch), hoặc phức tạp hơn (một CompositeProcess). Xem ví dụ AtomicProcess này (xem ví dụ 25).

Ví dụ 25. Process
<process:AtomicProcess rdf:ID="AmazonBookFinderProcess">
   <service:describes rdf:resource="#AmazonBookFinderService"/>

   <process:hasInput rdf:resource="#BookName"/>
   <process:hasOutput rdf:resource="#ItemInfo"/>
</process:AtomicProcess>

Bạn thấy đấy, tiến trình cũng chỉ tới các tham số vào ra.

Các tham số vào ra

Bạn cũng sử dụng OWL-S để xác định các tham số vào ra (xem ví dụ 26).

Ví dụ 26. Các tham số vào ra
<process:Input rdf:ID="BookName">
   <process:parameterType rdf:datatype=
         "&xsd;#anyURI">&xsd;#string</process:parameterType>
   <rdfs:label>Book Name</rdfs:label>
</process:Input>

<process:Output rdf:ID="ItemInfo">
   <process:parameterType rdf:datatype=
                 "&store;#StockItem</process:parameterType>
   <rdfs:label>Item Info</rdfs:label>
</process:Output>

Trong trường hợp này, tham số vào là một xâu chứa tiêu đề một quyển sách. Tham số ra từ dịch vụ OWL-S này là một thể hiện của StockItem đã miêu tả trong bản thể luận trước đó, liên kết một sách (book) đến một kho (store), chứa các thông về giá sách ở trong kho đó. Vì vậy, các tham số dịch vụ được liên kết với các đối tượng trong bản thể luận của bạn.

Grounding

Thứ ba và phức tạp nhất là thành phần Grounding trong một Service. Một Service hỗ trợ một Grounding. Thực chất, Grounding liên kết một tiến trình với một bản đồ thông điệp giao tiếp với một dịch vụ web. Trong thời gian giải phóng hiện tại của nó, OWL-S chỉ hỗ trợ các WSDL grounding, nhưng về nguyên tắc nó có thể hỗ trợ tốt các REST grounding. WSDL grounding trong OWL-S chỉ rõ URL cho dịch vụ, loại cổng và thao tác mong muốn, thông điệp đầu vào, một danh sách các bản đồ thông điệp vào (nó liên kết các tham số đầu vào với thông điệp WSDL một bộ phận của dịch vụ web), thông điệp ra, và một danh sách các ánh xạ thông điệp ra. Các phép ánh xạ thông điệp ra có thể bao gồm việc sử dụng các chuyển đổi XSLT. (xem ví dụ 27).

Ví dụ 27. Các phép ánh xạ đầu ra
<grounding:WsdlAtomicProcessGrounding
 rdf:ID="AmazonBookFinderProcessGrounding">
   <grounding:owlsProcess rdf:resource="#AmazonBookFinderProcess"/>
   <grounding:wsdlDocument rdf:datatype=
"&xsd;#anyURI">http://webservices.amazon.com/AWSECommerceService/AWSE
CommerceService.wsdl</grounding:wsdlDocument>
   <grounding:wsdlOperation>
      <grounding:WsdlOperationRef>
         <grounding:portType rdf:datatype=
"&xsd;#anyURI">http://webservices.amazon.com/AWSECommerceService/2006
-06-28</grounding:portType>
         <grounding:operation rdf:datatype=
"&xsd;#anyURI">http://webservices.amazon.com/AWSECommerceService/Item
Search</grounding:operation>
      </grounding:WsdlOperationRef>
   </grounding:wsdlOperation>

   <grounding:wsdlInputMessage rdf:datatype=
"&xsd;#anyURI">http://webservices.amazon.com/AWSECommerceService/Item
SearchRequest</grounding:wsdlInputMessage>
   <grounding:wsdlInput>
      <grounding:WsdlInputMessageMap>
         <grounding:owlsParameter rdf:resource="#BookName"/>
         <grounding:wsdlMessagePart rdf:datatype=
"&xsd;#anyURI">http://webservices.amazon.com/AWSECommerceService/Titl
e</grounding:wsdlMessagePart>
      </grounding:WsdlInputMessageMap>
   </grounding:wsdlInput>

   <grounding:wsdlOutputMessage
 rdf:datatype="&xsd;#anyURI">http://webservices.amazon.com/AWSECommerceSe
rvice/ItemSearchResponse</grounding:wsdlOutputMessage>
   <grounding:wsdlOutput>
      <grounding:WsdlOutputMessageMap>
         <grounding:owlsParameter rdf:resource="#StockInfo"/>
         <grounding:wsdlMessagePart 
rdf:datatype="&xsd;#anyURI">http://webservices.amazon.com/AWSECommerceServ
ice/ItemSearchResponse</grounding:wsdlMessagePart>
         <grounding:xsltTransformationString>
           <![CDATA[
<xsl:stylesheet version="1.0" 
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" >
   <xsl:output method="xml" version="1.0" encoding="UTF-8" 
indent="yes"/>
   <xsl:template match="/ ">
      <rdf:RDF 
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
         xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" 
         <store:StockItem>
            <store:itemPrice>
               <xsl:value-of 
select="http://webservices.amazon.com/AWSECommerceService/ItemSearchResponse/
OfferSummary/LowestPrice"/>
            </store:itemPrice>
         </store:StockItem>
      </rdf:RDF>
   </xsl:template>
</xsl:stylesheet>
           ]]>
         </grounding:xsltTransformationString>
      </grounding:WsdlOutputMessageMap>
   </grounding:wsdlOutput>
</grounding:WsdlAtomicProcessGrounding>

Để có một Mashup bạn có thể cần một đối tượng Service (với Profile, Process, và Grounding) cho mỗi dịch vụ web khác nhau. Ví dụ, bạn sẽ cần một cho Amazon và một cho Barnes và Noble.


Tóm tắt

Tổng hợp và định hướng tiếp theo

Ở bài này bạn đã tạo một bản thể luận, mang lại cho bạn ý tưởng bạn có thể phân lớp các khái niệm như thế nào để sử dụng trong một hệ thống đã dự kiến và thực hiện các quyết định trí tuệ cơ bản. Các chủ đề sau đã được thảo luận:

  • Nhìn chung về Ngôn ngữ Web Ontology Language (OWL)
  • Tạo các lớp, các lớp con, các thuộc tính như thế nào
  • Sử dụng các thuộc tính như thế nào để cho phép một ứng dụng làm các suy luận và thực thi suy diễn đơn giản
  • Các đặc trưng khác nhau của OWL
  • OWL-S, một phương pháp định nghĩa dữ liệu trên các dịch vụ Web

Trong phần 5 của loạt bài, bạn sẽ sử dụng một số tri thức thu được ở đây để mở rộng hệ thống hiện tại cho người dùng có thể chọn lựa các dịch vụ từ nơi mà họ muốn nhận thông tin.


Tải về

Mô tảTênKích thước
Phần 4 tệp stores.owlx-ultimashup4.source.zip2KB

Tài nguyên

Học tập

Lấy sản phẩm và công nghệ

Thảo luận

Bình luận

developerWorks: Đăng nhập

Các trường được đánh dấu hoa thị là bắt buộc (*).


Bạn cần một ID của IBM?
Bạn quên định danh?


Bạn quên mật khẩu?
Đổi mật khẩu

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Ở lần bạn đăng nhập đầu tiên vào trang developerWorks, một hồ sơ cá nhân của bạn được tạo ra. Thông tin trong bản hồ sơ này (tên bạn, nước/vùng lãnh thổ, và tên cơ quan) sẽ được trưng ra cho mọi người và sẽ đi cùng các nội dung mà bạn đăng, trừ khi bạn chọn việc ẩn tên cơ quan của bạn. Bạn có thể cập nhật tài khoản trên trang IBM bất cứ khi nào.

Thông tin gửi đi được đảm bảo an toàn.

Chọn tên hiển thị của bạn



Lần đầu tiên bạn đăng nhập vào trang developerWorks, một bản trích ngang được tạo ra cho bạn, bạn cần phải chọn một tên để hiển thị. Tên hiển thị của bạn sẽ đi kèm theo các nội dung mà bạn đăng tải trên developerWorks.

Tên hiển thị cần có từ 3 đến 30 ký tự. Tên xuất hiện của bạn phải là duy nhất trên trang Cộng đồng developerWorks và vì lí do an ninh nó không phải là địa chỉ email của bạn.

Các trường được đánh dấu hoa thị là bắt buộc (*).

(Tên hiển thị cần có từ 3 đến 30 ký tự)

Bằng việc nhấn Gửi, bạn đã đồng ý với các điều khoản sử dụng developerWorks Điều khoản sử dụng.

 


Thông tin gửi đi được đảm bảo an toàn.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=70
Zone=Information Management, Công nghệ Java, Nguồn mở, SOA và dịch vụ Web
ArticleID=391014
ArticleTitle=Ultimate mashup – Các dịch vụ Web và Web ngữ nghĩa (semantic Web), Phần 4: Tạo một bản thể luận
publish-date=03082007