Tóm tắt: Sức mạnh của Ultimate mashup là trí tuệ mà bạn phát triển bằng cách
sử dụng các kỹ thuật Web ngữ nghĩa, đặc biệt là Web ngôn ngữ bản thể luận (Web
Ontology Language - OWL). Nhưng trước khi bạn có thể sử dụng OWL, bạn cần
quen với ngôn ngữ cơ bản của chương trình này, đó là Resource Description
Framework (RDF) và RDF Schema Language (RDFs). Hướng dẫn này sẽ cung
cấp cho bạn kiến thức cơ bản khá tốt về cả RDF và RDFs để bạn sẵn sàng xây
dựng các bản thể luận (ontologies) cho công việc phát triển Web của bạn, và cũng
có thể tận dụng sức mạnh của RDF cho các dự án khác.
54 trang |
Chia sẻ: tlsuongmuoi | Lượt xem: 2381 | Lượt tải: 1
Bạn đang xem trước 20 trang tài liệu Đề tài Các dịch vụ Web và Web ngữ nghĩa (semantic Web) - Phần 3: Hiểu về RDF và ngôn ngữ lược đồ RDF, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
Ultimate mashup – Các dịch vụ Web và Web ngữ nghĩa (semantic Web),
Phần 3: Hiểu về RDF và ngôn ngữ lược đồ RDF
Tóm tắt: Sức mạnh của Ultimate mashup là trí tuệ mà bạn phát triển bằng cách
sử dụng các kỹ thuật Web ngữ nghĩa, đặc biệt là Web ngôn ngữ bản thể luận (Web
Ontology Language - OWL). Nhưng trước khi bạn có thể sử dụng OWL, bạn cần
quen với ngôn ngữ cơ bản của chương trình này, đó là Resource Description
Framework (RDF) và RDF Schema Language (RDFs). Hướng dẫn này sẽ cung
cấp cho bạn kiến thức cơ bản khá tốt về cả RDF và RDFs để bạn sẵn sàng xây
dựng các bản thể luận (ontologies) cho công việc phát triển Web của bạn, và cũng
có thể tận dụng sức mạnh của RDF cho các dự án khác.
Trước khi bạn bắt đầu
Hướng dẫn này là dành cho các lập trình viên phát triển web, những người quan
tâm tới việc học về RDF (Resource Description Framework), cũng như dành cho
những ai quan tâm tới việc học thêm về Web ngữ nghĩa và các dịch vụ Web ngữ
nghĩa nói chung và xây dựng các bản thể luận nói riêng. Bạn sẽ học cách xây dựng
và truyền tải thông tin RDF ở cả dạng XML phổ biến và dạng dùng nhanh phi
XML.
Hướng dẫn này không liên quan tới lập trình, nhưng giả định là bạn đã quen với
các khái niệm XML.
Về loạt bài này
Có vẻ như ngày nay bạn không thể quay lưng lại với Web mà không vào một trang
web mà nó cho phép truy cập vào dữ liệu trên trang web thông qua dịch vụ dựa
trên nền Web API hoặc sử dụng dữ liệu từ một trang khác thông qua dịch vụ Web
API. Khi bạn cân nhắc lợi ích của việc sử dụng thông tin hiện có trong các ứng
dụng của riêng bạn thì điều này có thể không quá bất ngờ. Điều này cũng từng chỉ
là vấn đề về thời gian trước khi ai đó đã bắt đầu kết hợp các thông tin từ các hệ
thống tách biệt để tạo nên một thứ gì đó hoàn toàn mới. Những ứng dụng này,
được gọi là mashup, là cái mới nhất trên Web, từ các trang tập trung vào cộng
đồng tới các trang tìm kiếm đặc thù và cho tới các mashup ánh xạ hiện thời (ever-
present mapping mashups).
Mashup hầu hết đều hữu dụng, nhưng có một vấn đề mà chúng thường hay có đó
là chúng đều được phát triển cho tập hợp các dịch vụ cụ thể. Nếu một trong những
dịch vụ đó thay đổi, hoặc nếu sự ưa chuộng đối với một dịch vụ cụ thể của một
loại hình nào đó thay đổi thì bạn sẽ phải làm rất nhiều việc.
Mục tiêu của loạt bài hướng dẫn này đó là tạo ra một trình ứng dụng mashup
thông minh tới mức người sử dụng có thể thêm bớt các dịch vụ nếu muốn, và hệ
thống sẽ biết làm gì với chúng. Các tiến trình của loạt bài như sau:
Trong Phần 1, tôi đã giới thiệu khái niệm của mashup, đã chỉ ra cách thức chúng
vận hành và phát triển một phiên bản đơn giản của chúng. Bạn cũng đã tìm ra các
vấn đề nghiêm trọng trong vận hành có liên quan tới việc tạo ra hàng loạt cuộc gọi
trên Web.
Ở Phần 2, bạn sẽ giải quyết một vài vấn đề trong đó bằng cách sử dụng tính năng
pureXML™ mới của DB2® để xây dựng nơi lưu trữ, là chỗ lưu các kết quả của
các yêu cầu từ trước đó và cũng cho phép bạn tìm lại các thông tin nào đó.
Trước tiên, bạn cần sử dụng các bản thể luận, hoặc từ vựng xác định khái niệm và
mối quan hệ của chúng, vì vậy ở đây trong Phần 3 bạn sẽ bắt đầu quy trình đó
bằng cách tìm hiểu về RDF và RDFS, là hai nhân tố chính trong OWL (Web
Ontology Language) mà tôi sẽ thảo luận trong Phần 4. Trong Phần 5, bạn sẽ lấy
các bản thể luận được tạo ra ở Phần 4 và sử dụng chúng để cho phép người sử
dụng thay đổi các nguồn thông tin.
Trong Phần 6, mọi thứ sẽ thực sự thú vị. Về điểm này thì bạn có một trình ứng
dụng đang hoạt động và khung đúng chỗ để hệ thống có thể sử dụng lập luận ngữ
nghĩa để hiểu được dịch vụ tại vị trí của nó. Trong phần này, bạn cho phép người
dùng kiểm soát, cho phép họ lấy và lựa chọn dữ liệu mà sẽ được sử dụng cho một
mashup tùy biến.
Về bài viết này
Trong phần trước của loạt bài này, bạn đã tạo ra nền tảng của mashup: servlet mà
kiểm tra bộ đệm lưu trữ (cache) cơ sở dữ liệu và hiển thị dữ liệu lưu trữ hoặc làm
mới. Bây giờ bạn cần bắt đầu đưa "ngữ nghĩa" vào Web. Trong Phần 4, bạn sẽ tạo
ra một bản thể cho phép bạn thực thi logic trong các dịch vụ của bạn, nhưng trước
hết bạn cần hiểu được ngôn ngữ mà bạn sẽ làm việc với bản thể luận đó, RDF -
Resource Description Framework.
Bài viết này giúp bạn theo được với RDF và các nhánh của nó, lược đồ RDF.
Trong hướng dẫn này, bạn sẽ tìm hiểu về:
RDF là gì và được sử dụng để làm gì
Mối quan hệ giữa RDF, lược đồ RDF, OWL, và Web ngữ nghĩa
Kiến thức cơ bản về RDF
Xử lý các nguồn, thành phần, và các cấu trúc RDF khác
Thể hiện RDF trong XML – và khi không có nó
Tạo các lớp và ví dụ sử dụng lược đồ RDF
Trong bài viết này, bạn sẽ xem qua những cấu trúc này từ quan điểm của việc biểu
diễn các thành phần và dữ liệu của bạn từ ứng dụng mashup của bạn.
Các điều kiện tiên quyết
Mặc dù bạn không cần các cấu phần phần mềm để mashup tự chạy – xem danh
sách các yêu cầu đối trong phần 2 (xem Tài nguyên)-- bài này chủ yếu bàn về các
khái niệm vì vậy bạn không cần một phần mềm cụ thể nào cả.
Khái quát nhanh
Trước khi bạn tiếp tục đi sâu, chúng ta hãy trao đổi về ví dụ ứng dụng mashup,
Web ngữ nghĩa, RDF và các bản thể luận.
Nhìn lại các phần trước
Một mashup là một ứng dụng và nó lấy dữ liệu, thường là dữ liệu dịch vụ Web, và
thường lấy từ nhiều nguồn – và nó được sử dụng để tạo ra một chương trình mới
nào đó. Cho tới nay, để bạn tạo được Ultimate mashup, bạn đã tạo một hệ thống
mà nó thể hiện thông tin cho một số bất kỳ các dịch vụ Web và trình bày thông tin
đó trên trang Web.
Ứng dụng được xây dựng để trở thành chung nhất có thể. Bạn có thể xác định các
dịch vụ theo lớp riêng của chúng, với một mảng các dịch vụ cần thể hiện. Để thêm
hoặc bớt dịch vụ từ đầu ra cuối cùng, bạn có thể tạo nội dụng của mảng đó, và một
mẫu XML mà xác định bản trình bày mới nhất sẽ kèm theo một định nghĩa về dịch
vụ.
Kết quả cuối cùng đó là bạn có thể kiểm soát các dịch vụ được sử dụng, nội dung
trình bày của dữ liệu trên trang Web cuối cùng, và thậm chí các dịch vụ con được
kết nối với dịch vụ chính bằng cách đơn giản là chế tác các lượng thông tin vào
các hướng dẫn đầu vào.
Lý do tôi làm mọi điều trở lên chung chung một phần là để có được sự linh hoạt và
khả năng bảo trì, và một phần là để chuẩn bị trình ứng dụng cho những gì sẽ tới
tiếp theo.
Vào cái sẽ tới tiếp theo đó là một cách thức mới để tìm kiếm thông tin.
Tiếp theo là Web ngữ nghĩa
Ngay bây giờ, khi bạn tìm tới một công cụ tìm kiếm như Google và nhập từ để tìm
thì thật khó để đoán được chính xác là bạn sẽ nhận lại thông tin thế nào. Nếu bạn
nhập từ "SOAP", có phải bạn sẽ nhận được một loạt các tài liệu trên các dịch vụ
Web, hoặc những chỉ dẫn về việc giặt là? Hoặc có phải là một thông tin cập nhật
rằng ai đã giết nhân vật Greg Madden trong tập phim truyền hình "Bọn trẻ của
tôi"?
Google làm được nhiều trong việc tìm ra một trang Web nào đó thuộc về ví dụ nào
bằng cách xem trang nào được kết nối tới, nhưng kết cục là chuỗi "SOAP" chỉ là
một chuỗi các chữ cái, và để nhận rõ ý nghĩa và nội dung của từ đó là một nhiệm
vụ mà hiện nay tốt nhất là để dành lại cho bộ não của con người.
Nhưng mọi thứ đều khác trên Web ngữ nghĩa. Trên Web ngữ nghĩa, thông tin
được xác định theo cách mà có thể máy móc hiểu được, và cho phép phần mềm xử
lý quy trình này.
Một ví dụ thường được sử dụng để trao đổi trong trường hợp này có liên quan tới
việc sắp xếp chuyến du lịch hoặc các công việc khác. Trên Web ngữ nghĩa, một
đại lý thông minh có thể kiểm tra kế hoạch của bạn, có thể giúp bạn tìm một
chuyên gia phù hợp với một cuộc hẹn gặp mà bạn có thể thiết lập, có thể lấy đánh
giá từ các bệnh nhân cũ và bệnh nhân hiện thời, và có thể thu xếp một người giữ
trẻ để trông nom con bạn khi bạn đi vắng.
Tất cả các ví dụ này đều có khả năng thực hiện chỉ khi thông tin được đưa lên Web
ngữ nghĩa được xác định bằng máy cách mà máy có khả năng đọc và hiểu.
Nhưng ở đây là thủ thuật. Web ngữ nghĩa không phải là một sân chơi mới mẻ nào
đó mà ở đó những người sử dụng cần phải loại bỏ Web hiện thời. Không phải vậy,
Web ngữ nghĩa chỉ là trang Web hiện thời, nhưng với nhiều thông tin hơn.
Các dịch vụ Web ngữ nghĩa
Nếu bạn đưa các dịch vụ web vào mashup và dữ liệu của chúng theo cách này, với
nhiều thông tin hơn thì bạn có thể cho phép trình ứng dụng tạo ra các lựa chọn
thông minh. Ví dụ, trình ứng dụng có thể hiểu được dịch vụ nào thể hiện thông tin
bản đồ, và dịch vụ nào thể hiện các cửa hàng trực tuyến, hay thậm chí là sâu hơn,
các cửa hàng sách trực tuyến. Nó sẽ biết thông tin nào từ các dịch vụ đó thể hiện
tiêu đề, nội dung mô tả, giá cả và các thông tin khác nữa.
Đó là các dịch vụ hứa hẹn của Web ngữ nghĩa; một hệ thống hiểu được ý nghĩa
đằng sau các thông tin, làm cho thông tin có thể sử dụng được theo những cách cụ
thể.
Trong hướng dẫn này, nó có nghĩa những người sử dụng của bạn có thể tự động
hoán đổi các dịch vụ cùng loại – ví dụ như sử dụng Barnes và Noble thay vì
Amazon -- hoặc thậm chí tạo những mashup mới của riêng họ.
Cấu trúc mà bạn xác định thông tin này được gọi là bản thể luận.
Các bản thể luận
Trong cuốn sách Website Indexing 2nd Edition, Glenda Browne và John Jermey
định nghĩa từ bản thể luận như sau:
"Bản thể luận: Đặc tả kỹ thuật của việc khái quát hóa một miền kiến thức. Một
bản thể luận là các từ vựng được kiểm soát mà nó mô tả các đối tượng và các mối
quan hệ giữa chúng theo một cách chính thức, và có phần ngữ pháp để sử dụng các
thuật ngữ trong từ vựng để diễn giải điều gì đó có nghĩa trong một khoảng xác
định. Từ vựng được sử dụng để tạo các yêu cầu và các xác nhận. Các cam kết
thuộc bản thể luận là các thỏa thuận để sử dụng từ vựng theo cách ổn định để chia
sẻ kiến thức. Các bản thể luận có thể bao gồm các các danh sách từ (glossaries),
các phân loại (taxonomies) và các từ đồng nghĩa (thesauri), nhưng thông thường
có cách diễn giải tốt hơn và các quy định chặt chẽ hơn các công cụ này. Một bản
thể luận chính thức là một từ vựng được kiểm soát đã được diễn giải theo một
ngôn ngữ thể hiện bản thể."
Nói cách khác, một bản thể luận là một cách thức được thỏa thuận để diễn đạt các
ý tưởng cụ thể. Vì vậy, nếu tôi muốn làm cho thông tin của trang cá nhân của tôi
sẵn có, tôi có thể đưa lên các thông tin kiểu như thế này (xem Ví dụ 1):
Ví dụ 1. Thông tin được mã hóa sử dụng Dublin Core
<rdf:RDF
xmlns:rdf=""
xmlns:dc="">
Nicholas Chase
Chaos Magnet
The personal and professional ramblings
of technology author Nicholas Chase
2006-06-30
Thông tin này được thể hiện bằng cách sử dụng các thuật ngữ từ một cấu trúc được
gọi là Dublin Core. Dù bạn có thể gọi Dublin Core một bản thể luận lại để tranh
luận hoặc không, nhưng chắc chắn là mọi người sẽ đồng ý răng ý nghĩa về ngữ
nghĩa của người sáng tạo, tiêu đề, ngày tháng và các thông tin khác nữa.
Trong trường hợp này, bạn có thể tạo ra một bản thể luận mà có thể xác định được
các khái niệm ví dụ như:
Dịch vụ
Bản đồ
Cửa hàng
Cửa hàng sách
Giá cả
Bình luận
Hình ảnh
Ảnh thu nhỏ
Tiêu đề
Sau đó bạn có thể xác định các dịch vụ hoặc dữ liệu đơn lẻ như "các ví dụ" của
một trong các khái niệm này. Để làm được điều này, bạn sẽ sử dụng Ngôn ngữ
Bản thể luận Web (OWL).
Ngôn ngữ Bản thể luận Web (OWL)
Vâng tôi biết. Từ ghép đối với Ngôn ngữ Bản thể luận Web nên là WOL chứ
không phải là OWL. Nhưng lại không phải vậy, lý do là từ các tham chiếu tới
Winnie the Pooh (và Owl khôn ngoan, người đã đánh vần tên mình là W-O-L) cho
tới sự tôn trọng các dự án bản thể luận trước đó như Ngôn ngữ một thế giới (One
World Language) của Bill Martin cho tới thực tế rằng thật dễ dàng để nói và để
thiết kế những nhãn hiệu dành cho "OWL" hơn là cho "WOL".
Không vấn đề gì, và bây giờ cái đó đã được bỏ qua, vậy chính xác đó là gì?
One World Language, hay viết tắt là OWL, cung cấp một từ vựng để xác định
thông tin trên Web theo cách mà các máy móc có thể diễn giải được nó. Hãy xem
xét ví dụ này (xem Ví dụ 2):
Ví dụ 2. Một bản thể luận (rất) đơn giản
<rdf:RDF
xmlns =""
xml:base =""
xmlns:owl =""
xmlns:rdf =""
xmlns:rdfs="">
Online Store
Bookstore
Mã trong ví dụ 2 tạo ra một loại đối tượng chính, một cửa hàng Store, và một lớp
con, cửa hàng sách Bookstore. Sau đó bạn có thể sử dụng loại mới đó để xác định
Amazon.com là một Bookstore.
Không quá thú vị cho tới khi bạn xem xét thấy rằng OWL cũng cho phép bạn tạo
hàng loạt các xác nhận về các Bookstore, ví dụ như thực tế là chúng có thể truy
cập trực tuyến, chúng bán sách (cái mà bạn có thể xác định theo kiểu riêng của
bạn), mà bạn cũng có thể bán các loại hàng khác, và hơn thế nữa. Bằng cách xác
định Amazon.com là một Bookstore, tất cả những thông tin đó tự động gắn với nó.
Bạn sẽ tìm hiểu mọi thứ về OWL trong Phần 4 của loạt bài này, nhưng trước khi
bạn tới đó, bạn cần gọi tên dạng thức của thông tin, đó là Khung Mô tả Tài nguyên
(Resource Description Framework).
Khung Mô tả Tài nguyên (RDF)
Khung Mô tả tài nguyên là một cách thức rõ ràng để nêu thông tin về thứ gì đó.
Nhiều người cho rằng nó quá phức tạp, nhưng khi bạn nhìn nhận đúng về nó thì
RDF chỉ là cách để xác định đặc tính của các nguồn. Quay trở lại ví dụ trang web
cá nhân (xem Ví dụ 3):
Ví dụ 3. Xác định đặc tính của các nguồn
<rdf:RDF
xmlns:rdf=""
xmlns:dc="">
Nicholas Chase
Chaos Magnet
The personal and professional ramblings
of technology author Nicholas Chase
2006-06-30
Trong ví dụ 3, mã tạo ra một mô tả Description đó là về một nguồn
Mã xác định bốn đặc tính, dc:creator, dc:title,
dc:Description, và dc:date, và giá trị của các đặc tính đó. Trong hướng dẫn này, tôi
sẽ dùng các đồ thị và các bộ ba (triples) và các nguồn và tất cả các thứ mà có thể
làm cho RDF dường như quá phức tạp, nhưng cuối cùng, đây là những gì mà thực
sự là nó: gán các đặc tính vào các nguồn theo một cách được thỏa thuận trước.
Lược đồ khung mô tả tài nguyên (RDFs)
Như tôi đã nói, RDF là một cách để gán các đặc tính vào các nguồn, và chỉ có vậy.
Bản thân RDF thậm chí không gán bất cứ nghĩa nào vào các đặc tính đó. Bất cứ
nghĩa nào trong một tài liệu RDF đến từ các đặc tính, và không phải từ RDF.
Không may là điều này có nghĩa là bản thân RDF không phải là rất hữu dụng đối
với các công việc như định nghĩa các từ vựng, trong đó bạn cần một cách thức để
xác định ít nhất là các quan hệ giữa các khái niệm.
Nhập lược đồ RDF. Một phần của nhóm các đặc tả được cho là "Bản khuyến nghị
của RDF", lược đồ RDF cung cấp cách thức để tạo ra những quan hệ cơ bản để
xác định từ vựng. Hãy xem ví dụ này (xem ví dụ 4):
Ví dụ 4. Một ví dụ đơn giản về lược đồ RDF
<rdf:RDF
xmlns =""
xml:base =""
xmlns:rdf =""
xmlns:rdfs="">
Web Service
Online Store
Bookstore
Trong ví dụ 4, mã tạo ra ba lớp Class và một đặc tính Property, endpoint. (Tôi sẽ
không thảo luận về OWL cho tới Phần 4.) Bạn có thể gán đặc tính đó vào bất kỳ
dịch vụ Service nào (điều này nghĩa là có thể áp dụng vào Bookstore, như một lớp
con của Store, một lớp con của Service) và cần một giá trị anyURI như đã được
định nghĩa bởi bản khuyến nghị của Sơ đồ XML.
Lược đồ RDF cung cấp các khái niệm này như một tập hợp các khối cơ bản
(building block) mà bạn có thể sử dụng để phát triển các ngôn ngữ và bản thể luận
mới. Trong Phần 4, chúng ta sẽ xem cách thức mà các khái niệm của RDF đưa vào
để tạo thành OWL, nhưng trước hết, trong hướng dẫn này, bạn sẽ tìm ra cách thức
mà nó vận hành.
Hãy bắt đầu với RDF.
Cơ bản về RDF
Tôi đã thấy các lập trình viên với nhiều năm kinh nghiệm đã tức tưởi khi bắt đầu
xử lý trên RDF, nhưng nó thực sự không khó khăn như vậy. Trong phần này, bạn
sẽ tìm hiểu những kiến thức cơ bản để bạn cũng có thể nói được rằng "Hãy vượt
qua nó, nó không quá khó đâu."
Các nguồn RDF
Cái tên Khung Mô tả Tài nguyên cho bạn thấy thực tế rằng bạn đang mô tả các tài
nguyên, nhưng thực ra chúng là thế nào?
Một nguồn có thể là về bất cứ thứ gì, cho dù nó hữu hình (như một người), hay vô
hình, ví dụ như chức danh hay cơ hội. Điều quan trọng là bạn cẩn có thể tham
chiếu nó và sử dụng định danh của nguồn đồng nhất (Uniform Resource Identifier-
URI). Một loại URI là địa chỉ tài nguyên đồng nhất (Uniform Resource Locator-
URL), là những thứ mà bạn đã quen thấy trên Internet, như trên
hay mailto:ibmquestions@nicholaschase.com. Nhưng các
URI cũng có thể chung chung hơn, ví dụ như urn:backstopmedia, đây là tên nguồn
đồng nhất (Uniform Resource Name-URN) thay vì là URL.
Điều này nghĩa là bạn có thế sử dụng các URL để xác định các nguồn như các
trang Web và hộp thư điện tử -- các nguồn trong đó một URL có thể cung cấp
thông tin khi tìm kiếm nó – và các URN để xác định các nguồn khác. Ví dụ, bạn
có thể quyết định xác định một người (ít nhất ở Hoa Kỳ) với một URN tham chiếu
Số An ninh Xã hội của họ, như trong ssn:078-05-1120. Dĩ nhiên, trong thời đại ăn
cắp thông tin cá nhân này thì bạn có lẽ không muốn làm như vậy, vì vậy bạn
thường gặp những người được tham chiếu như một URL với một ý nghĩa đã được
thỏa thuận trước nào đó, ví dụ như địa chỉ trang chủ trang web của họ
( hoặc URL nội bộ (ví dụ như
Một điều quan trọng đó là bạn cần có khả năng xác định nguồn với một loại URI
nào đó. Dạng thức mà cuối cùng nó thể hiện không quan trọng.
Đặc tính RDF
Để mô tả một nguồn mà sử dụng RDF, hãy gán cho nó các đặc tính. Bạn có thể
phân giai đoạn gán các đặc tính này thành các câu. Ví dụ (xem Ví dụ 5):
Ví dụ 5. Gán các đặc tính
Nick's blog has a name of Chaos Magnet
Nick's blog has a creator of Nicholas Chase
Trong mỗi một câu này, bạn có một chủ thể (Nick's blog) một tính chất (has a
name, has a creator) và một chủ thể (Chaos Magnet, Nicholas Chase). Chủ thể này
đại diện cho nguồn, tính chất, thuộc tính, và chủ thể giá trị của đặc tính. Vì vậy
nếu bạn chuyển các câu này sang dạng nào đó gần với một RDF triple, bạn sẽ
nhận được những thứ được chỉ ra trong Ví dụ 6:
Ví dụ 6. Phân chia các mục
Nick's blog name Chaos Magnet .
Nick's blog creator Nicholas Chase .
Dĩ nhiên, tôi thể hiện nguồn như một URI, vì vậy thay vào đó nó sẽ là thứ gì đó
giống như (xem Ví dụ 7):
Ví dụ 7. Thể hiện các nguồn dưới dạng như các URI
name Chaos Magnet .
creator Nicholas Chase .
Đây vẫn không thực sự là một RDF triple bởi vì nó có một chuỗi nguyên dành cho
các đặc tính. Vấn đề ở đây là các đặc tính, giống như các nguồn, cần được thể hiện
dưới dạng như một URI.
Các tham chiếu URI
Thực ra, bạn thể hiện các đặc tính dưới dạng như một tham chiếu URI, hay viết tắt
là URIref, là cái bao gồm cơ sở của đặc tính – theo phương thức thực tế, tên trống
mà đặc tính đó thuộc về -- được tiếp theo bởi một phân đoạn (fragment).
Ví dụ, trong ví dụ 7, tôi đã tham chiếu tới thuộc tính creator. Thực ra, đây là thuộc
tính creator được xác định bởi không gian tên Dublin Core, vì vậy tham chiếu
URIref đầy đủ sẽ là (xem ví dụ 8):
Ví dụ 8. URIref đầy đủ cho tên khởi tạo
Nếu bạn là một lập trình viên phát triển Web, thì cú pháp cuối cùng, phân đoạn bắt
đầu với ký hiệu dấu thăng (#) có thể thấy quen thuộc. Cùng cú pháp mà bạn dùng
để gửi trình duyệt tới một điểm nhất định trên trang web, ví dụ như (xem ví dụ 9):
Ví dụ 9. URL, bao gồm phân đoạn
https://www6.software.ibm.com/developerworks/education/ws-understand-
web-services3/#N1014F
Để tạo điểm đó trên trang web, bạn có thể tạo một thẻ neo (anchor tag) của (xem
ví dụ 10):
Ví dụ 10. Tạo một thẻ neo
:
Với sự trông đợi của XHTML, phiên bản XML của HTML, bản này đổi thành
(xem Ví dụ 11):
Ví dụ 11. XHTML thẻ neo
Vì vậy đoạn tham chiếu tới yếu tố đó là ký hiệu dấu thăng (#) và do vậy là giá trị
của thuộc tính ID. (Đối với những ai đã quen với XPointer, điều này có thể đã rõ.)
Sau này khi bạn tạo các nguồn sử dụng rdf:ID attribute, bạn sẽ thấy lại phần này,
nhưng bây giờ quan điểm của tôi đó là một URIref là một URL, có thể với một
đoạn đính kèm.
Đó cũng chỉ là một cách có thể chấp nhận được để xác định một đặc tính RDF. Vì
vậy các câu sẽ thành (xem ví dụ 12):
Ví dụ 12. Các đặc tính dưới dạng như các URIrefs
Chaos Magnet .
Nicholas Chase .
Trong một số trường hợp, bạn muốn viết tắt tất cả những thứ đó, vậy bạn có thể
gán một tiền tố để thể hiện không gian tên thực sự. Việc này cho phép bạn cắt các
câu xuống ví dụ 13:
Ví dụ 13. Cắt ngắn các câu
ex:name Chaos Magnet .
dc:creator Nicholas Chase .
Đây gần hơn với dạng RDF thực sự, nhưng chưa hẳn ở đó.
Các giá trị đặc tính
Cho tới nay tất cả các đặc tính mà bạn đã thấy đều có các giá trị chuỗi đơn giản,
nhưng trên thực tế các trường hợp đó là thiểu số. Để hiểu được tại sao, bạn cần
xem xét mọi thứ theo ngữ nghĩa đen. Khi tôi nói "trang web cá nhân của Nick có
một tên khởi tạo là 'Nicholas Chase'", đó thực chất là một câu không có ý nghĩa
lắm. Một chuỗi các chữ cái ("Nicholas Chase") đã không tạo trang web cá nhân
của tôi (thậm chí nếu nó dường như đôi lúc theo cách như vậy). Ý tôi thực sự
muốn nói đó là "Nguồn được biết tới là “trang web cá nhân của Nick's” đã được
tạo ra bởi nguồn được biết đến là 'Nicholas Chase'."
Vì vậy, triple thực sự có thể giống một số thứ hơn điều này (xem ví dụ 14):
Ví dụ 14. Tiến gần hơn tới triple
dc:creator
Bạn có thể thể hiện điều này trong một đồ thị RDF.
Đồ thị RDF
Một cách để thể hiện tất cả thông tin này là thông qua việc sử dụng các đồ thị
RDF. Trong các đồ thị này, bạn có thể thấy mọi thứ khớp với nhau như thế nào. Ví
dụ, xem Hình 1:
Hình 1. Một đồ thị RDF
Các nútt hình ô van thể hiện các nguồn, với các mũi tên giữa các hình thể hiện các
đặc tính. Giá trị các đặc tính mà các nguồn được chỉ ra bằng các hình ôvan, với
các giá trị theo nguyên văn được chỉ ra trong các hộp.
Các ký hiệu chú giải RDF
Cho tới nay bạn đã thấy qua thông tin về RDF, nhưng bạn chưa nhìn nhận chính
thức về cách thể hiện nó. Bạn có thể sử dụng các triple, trong đó nguồn các URIref
được viết trong trạng thái nguyên vẹn của chúng (xem ví dụ 15):
Ví dụ 15. Các triple đầy đủ URIref
Chaos Magnet .
.
(Các ràng buộc khoảng trống có hiệu lực ở đây, nhưng mỗi triple thông thường
được viết trên một dòng.)
Bạn cũng có thể sử dụng tốc ký, thay thế các không gian tên với các tiền tố (xem
ví dụ 16):
Ví dụ 16. Ký hiệu Shorthand
@prefix ex: .
@prefix dc: .
ex:name "Chaos Magnet" .
dc:creator
.
Chú ý rằng chỉ các URIrefs đầy đủ được hiển thị trong các dấu ngoặc. Có lẽ cách
phổ biến nhất để xem RDF, tuy nhiên, lại như XML. Ví dụ, bạn sẽ thấy những mối
quan hệ này như (xem ví dụ 17):
Ví dụ 17. Ký hiệu XML
<rdf:RDF
xmlns:rdf=""
xmlns:ex = ""
xmlns:dc="">
Chaos Magnet
Bạn sẽ thấy rõ hơn về cách hiển thị RDF trong XML trong phần tiếp theo.
RDF/XML
XML không phải là cách duy nhất để hiển thị RDF. Trong một số trường hợp, nhất
là khi bạn cố gắng hình dung mối quan hệ giữa các nguồn và các đặc tính, thậm
chí đó không phải là cách tốt nhất. Nhưng chắc chắn đó là cách thông dụng nhất,
và khi được thực hiện với Web ngữ nghĩa, là cách thuận tiện nhất. Hãy xem cách
thức vận hành một cách chi tiết hơn.
Mô tả các nguồn đã tồn tại
Việc sử dụng RDF phổ biến nhất đó là mô tả các nguồn đã tồn tại, ví dụ như tất cả
hoặc một phần của một RSS feed. Trong các trường hợp đó, RDF được gộp trong
một tài liệu XML khác và được phần biệt thông qua việc sử dụng các không gian
tên XML. Tuy nhiên để đơn giản hơn, chúng ta hay xem xét riêng RDF.
Tôi sẽ bắt đầu với một tài liệu đơn giản mô tả dữ liệu được trả lại bởi một yêu cầu
đối với thẻ "movies" của Technorati (xem Ví dụ 18):
Ví dụ 18. Hãy mô tả một nguồn đã tồn tại
<rdf:RDF
xmlns:rdf="
syntax-ns#"
xmlns:tapi="">
<rdf:Description
rdf:about="">
[Technorati] Tag results for
Movies
Sun, 30 Jul 2006 11:38:42
PST
321580
Đây là một yếu tố đơn giản rdf:RDF với một mô tả Description bao gồm các đặc
tính cho nguồn được mô tả trong đặc tính rdf:about. Trong trường hợp này, các
đặc tính là từ không gian tên vì vậy nếu bạn mở
rộng các không gian tên, chúng ta thấy rằng thuộc tính title, ví dụ như vậy, thực sự
là thuộc tính của
Theo cách này, bạn có thể thêm bao nhiêu đặc tính vào nguồn là tùy thuộc vào
bạn.
Cũng cần chú ý rằng đây không chỉ là cách để hiển thị RDF trong XML. Do bởi
bạn thường kèm RDF trong các tài liệu khác, bạn luôn làm như vậy để họ không
động chạm tới thông tin gốc. Tuy nhiên cách mà tôi thể hiện các dữ liệu ở đây là
nếu tôi đã thêm thông tin vào trình duyệt, thì nội dung văn bản của các thành tố đó
sẽ xuất hiện trên trang web. Đây chỉ là cách thức mà dĩ nhiên cần như vậy, hiển thị
hành vi mặc định của trình duyệt một cách đơn giản thể hiện nội dung của bất kỳ
các phiên nào mà nó không hiểu được.
Để tránh vấn đề đó, chúng ta có thể sử dụng phương pháp thay thế bằng cách sắp
xếp thông tin theo các thuộc tính thay vì các thành tố. (xem Ví dụ 19):
Ví dụ 19. Dữ liệu RDF trong các thành tố
<rdf:RDF
xmlns:rdf=""
xmlns:tapi="">
<rdf:Description rdf:about=""
tapi:Title="[Technorati] Tag results for Movies"
tapi:PubDate="Sun, 30 Jul 2006 11:38:42 PST"
tapi:Inboundlinks="321580" />
Thông tin tương tự, nhưng hiện nay nó được chứa trong các giá trị thuộc tính hơn
là nội dung thành tố, và nó sẽ không được thể hiện bởi một trình duyệt.
Xác định loại dữ liệu
Đôi khi bạn muốn cụ thể hóa cách thức dữ liệu được xử lý, vì vậy thật hữu ích để
có thể cụ thể một loại dữ liệu dự định. Ví dụ (xem Ví dụ 20):
Ví dụ 20. Xác định các loại dữ liệu
<rdf:RDF
xmlns:rdf=""
xmlns:tapi="">
[Technorati] Tag results for Movies
<tapi:PubDate
rdf:datatype="">
Sun, 30 Jul 2006 11:38:42 PST
<tapi:Inboundlinks
rdf:datatype="">
321580
Trong trường hợp này, tôi xác định các thành tố PubDate và Inboundlinks nên là
ngày tháng và số nguyên như đã được xác định trong đặc tả lược đồ XML. Bạn có
thể nói rằng phiên bản Lược đồ XML của các loại này được dựa trên các không
gian tên trong các URIref của chúng. Không có gì nói rằng bạn cần sử dụng loại
dữ liệu Lược đồ XML, nhưng chúng là trong tầm tay và các trình ứng dụng XML
thường đã hiểu chúng, vì vậy không có lý do gì để không sử dụng chúng.
Bạn cũng có thể hiện thị loại trong ký hiệu N3, như trong (xem Ví dụ 21):
Ví dụ 21. Xác định các loại dữ liệu trong ký hiệu N3
"321580"^^ .
Cần chú ý rằng bản thân RDF không đóng vai trò gì để bắt buộc hoặc duyệt các
loại dữ liệu này. Không có gì có thể ngăn bạn nhập một chuỗi hoặc một số cho
một URL. RDF đơn giản là cung cấp cách thức để biểu thị thông tin; trình ứng
dụng RDF có trách nhiệm đảm bảo dữ liệu thích hợp.
Tham khảo các nguồn hiện thời
Đôi khi bạn chỉ mô tả các nguồn hiện thời, bạn sử dụng chúng để mô tả các nguồn
khác. Ví dụ, bạn có thể thêm vào nguồn mà bạn mô tả và thêm vào đặc tính Hình
ảnh. (xem Ví dụ 22):
Ví dụ 22. Tham khảo một nguồn như một giá trị đặc tính
<rdf:RDF
xmlns:rdf=""
xmlns:tapi="">
[Technorati] Tag results for Movies
<tapi:PubDate
rdf:datatype="">
Sun, 30 Jul 2006 11:38:42 PST
<tapi:Inboundlinks
rdf:datatype="">
321580
<tapi:Image rdf:resource
""/>
Hãy chú ý rằng bạn xác định các giá trị như một rdf:resource, và sử dụng các URI
của nguồn đó như giá trị đặc tính thực sự. Tuy nhiên trong một số trường hợp,
nguồn mà bạn muốn tham chiếu không được xác định bên ngoài không gian tên
hiện thời. Ví dụ, sẽ ra sao nếu hình ảnh mà bạn tham chiếu không chỉ là tệp mà
bạn có thể tham chiếu bằng một URL đơn, hơn là một tập hợp các đặc tính? Bạn
cần một cách thức để chỉ tới định nghĩa của nguồn đó.
Để làm được điều đó, hãy tạo bản thành tố Description thứ hai và gán cho nó một
nodeID (xem Ví dụ 23):
Ví dụ 23. Sử dụng các nốt ẩn danh
<rdf:RDF
xmlns:rdf=""
xmlns:tapi="">
[Technorati] Tag results for Movies
Sun, 30 Jul 2006 11:38:42 PST
<tapi:Inboundlinks
rdf:datatype="">
321580
Technorati logo
Cần chú ý rằng bạn tạo bản thành tố Description thứ hai và gán cho nó một
nodeID. Việc này cho phép bạn tạo một nguồn mà bạn có thể tham chiếu từ đặc
tính tapi:image. Nó được gọi là một nodeID, bởi nếu bạn đã định lấy dữ liệu từ đồ
thị RDF thì nốt image1 trong Hình 1 ở trên sẽ là nốt ôvan rỗng với đặc tính riêng
của nó.
Tạo các nguồn mới
Sử dụng nodeID tạo một cách thức để tham chiếu nốt này, nhưng chỉ trong ngữ
cảnh của tài liệu và không gian tên này. Tuy nhiên, đôi khi bạn muốn tạo một
nguồn mà bạn có thể tham chiếu từ bất cứ đâu, bao gồm các tài liệu khác và các
không gian tên khác.
Bạn có thể làm như vậy khi sử dụng thuộc tính rdf:ID (xem Ví dụ 24):
Ví dụ 24. Tạo một nguồn mới
<rdf:RDF
xmlns:rdf=""
xmlns:tapi="">
[Technorati] Tag results for Movies
<tapi:PubDate
rdf:datatype="">
Sun, 30 Jul 2006 11:38:42 PST
<tapi:Inboundlinks
rdf:datatype="">
321580
Technorati logo
Hãy nhớ là tôi đã nói tới trong một tài liệu XML về cách xác định một thành tố với
một thuộc tính ID cho phép bạn tạo một đoạn bằng cách tham chiếu tới nó? Còn
lúc này bạn sẽ thấy nó qua thực tế. Bạn đã tạo một nguồn mới và cho nó một ID
image1, điều này cho phép bạn tham chiếu nó với URI tương đối #image1.
Bây giờ hãy ghi chú lại rằng tôi đã nói nó là một URI tương đối. URI đầy đủ dành
cho nguồn này là URI cơ bản cho tài liệu theo sau là một phân đoạn. Ví dụ, khi tôi
chạy tài liệu này qua RDF validator, tôi nhận được một URI
Dĩ nhiên, điều này không thể dự đoán được, vì vậy bạn nên xác định URI cơ bản
trực tiếp qua cách sử dụng thuộc tính xml:base (xem Ví dụ 25):
Ví dụ 25. Xác định một URI cơ bản
<rdf:RDF
xmlns:rdf=""
xmlns:tapi=""
xml:base="">
[Technorati] Tag results for Movies
<tapi:PubDate
rdf:datatype="">
Sun, 30 Jul 2006 11:38:42 PST
<tapi:Inboundlinks
rdf:datatype="">
321580
Technorati logo
Bây giờ bạn có thể nói chắc chắn rằng không có vấn đề gì với dữ liệu được sắp
xếp, URI đầy đủ dành cho nguồn ảnh sẽ là
Sự nhất quán này cho phép bạn tham chiếu nguồn này từ bất kỳ đâu, bao gồm các
tài liệu khác và các không gian tên khác.
Cần chú ý giá trị của rdf:ID thuộc tính phải nhất quản trong một tên trông, vì vậy
bạn cần phải xác định nguồn cụ thể trông một thành tố.
Sử dụng nhiều mô tả description
Cho tới lúc này, mỗi khi bạn tạo hoặc mô tả một nguồn, nó sẽ nằm trong thành tố
đơn Description, nhưng điều này không cần thiết. Bạn có thể phân chia mô tả từ
thông tin gốc đầu vào thành một số thành tố Description khác nhau (xem Ví dụ
26):
Ví dụ 26. Tạo một nguồn với nhiều thành tố Description
<rdf:RDF
xmlns:rdf=""
xmlns:tapi=""
xml:base="">
[Technorati] Tag results for Movies
<tapi:PubDate
rdf:datatype="">
Sun, 30 Jul 2006 11:38:42 PST
<tapi:Inboundlinks
rdf:datatype="">
321580
Technorati logo
Điều thú vị đặc biệt của dạng mô tả này đó là không có giới hạn nào với nơi các
thành tố Description phải có mặt. Bạn có thể tạo ra một nguồn bao gồm thông tin
từ khắp nơi trên thế giới, tới khi mà mọi người liên quan có các thông tin thích
hợp.
Định rõ các kiểu
Khi bạn bắt đầu xây dựng các bản thể luận, bạn sẽ bắt đầu tạo các kiểu nguồn. Ví
dụ, bạn có thể tạo một kiểu Dịch vụ, một kiểu Giá cả, và các kiểu khác nữa, để bạn
có thể phân loại thông tin từ các dịch vụ khác nhau. Việc phân loại thông tin này
liên quan tới thiết lập thành “type” cho dữ liệu (xem Ví dụ 27):
Listing 27. Setting a date type
<rdf:RDF
xmlns:rdf=""
xmlns:tapi=""
xml:base="">
[Technorati] Tag results for Movies
<tapi:PubDate
rdf:datatype="">
Sun, 30 Jul 2006 11:38:42 PST
<tapi:Inboundlinks
rdf:datatype="">
321580
...
Cho tới thời điểm này, đây chỉ là kiểu bất kỳ; bạn hãy xem qua các kiểu xác định
khi bạn nhìn vào lược đồ RDF.
Các dạng khác: các kiểu được coi như tên thành tố
Một khi bạn xác định dữ liệu là một kiểu nhất định thì bạn có lựa chọn để diễn giải
nó theo cách gọn gàng hơn là thiết lập thuộc tính rdf:type. Thay vào đó, bạn có thể
sử dụng tên của loại vào chỗ của thành tố Description (xem Ví dụ 28):
Ví dụ 28. Sử dụng tên loại như tên thành tố
<rdf:RDF
xmlns:rdf=""
xmlns:tapi=""
xml:base=""
xmlns:mashup="">
[Technorati] Tag results for Movies
<tapi:PubDate
rdf:datatype="">
Sun, 30 Jul 2006 11:38:42 PST
<tapi:Inboundlinks
rdf:datatype="">
321580
...
Đoạn mã này định nghĩa tiền tố mashup: để biểu thị không gian tên
Vì vậy bạn thiết lập kiểu dữ liệu như
giống như ví dụ trước.
Dạng biểu thị các loại dữ liệu này trở nên quan trọng, và hầu như rộng khắp khi
bạn bắt đầu nói về OWL, và hẹp hơn là về lược đồ RDF.
Túi (Bag), trình tự (Sequence), và thay thế (alternative)
Cho tới nay bạn đã xử lý với các đặc tính có giá trị đơn và chuyên biệt, nhưng nếu
bạn đã từng xử lý với dữ liệu trong thế giới thực thì bạn biết rằng điều này không
phải luôn đúng. Hầu hết các hệ thống hữu dụng nào có ít nhất một hoặc từ một tới
nhiều quan hệ. Ví dụ, đầu vào mà bạn đang xem xét có thông tin về chính nó,
nhưng nó cũng có hàng tá hoặc một số các thực thể liên quan tới nó.
Trong RDF, bạn có thể diễn giải các mối quan hệ này theo nhiều cách khác nhau.
Cách đơn giản nhất là dùng Bag (xem Ví dụ 29):
Ví dụ 29. Diễn giải quan hệ từ một tới nhiều như một Bag
<rdf:RDF
xmlns:rdf=""
xmlns:tapi=""
xml:base=""
xmlns:mashup="">
[Technorati] Tag results for Movies
<tapi:PubDate
rdf:datatype="">
Sun, 30 Jul 2006 11:38:42 PST
<tapi:Inboundlinks
rdf:datatype="">
321580
<rdf:li rdf:resource="
review-lady-in-the-water/"/>
<rdf:li
rdf:resource=""/>
...
Về mặt nội tại, RDF đánh số mỗi một mục bên trong Bag, nhưng để thuận tiện
hơn, nó cũng cung cấp thành tố rdf:li (được mô hình hóa trong danh mục HTML).
Một rdf:Bag là đúng như cách nói, khi bạn tiếp cận nó. Nó là một loạt các mục
được nhóm lại với nhau và không theo thứ tự cụ thể nào. Mỗi một mục trong Bag
có vai trò quan trọng như nhau.
Tất nhiên đôi khi nó không như những gì bạn mong muốn. Ví dụ, các mục được
xếp đặt theo trình tự đảo ngược trình tự thời gian: thứ tự là quan trọng. Thay vào
đó, để diễn giải thì bạn có thể tạo một Sequence (xem Ví dụ 30):
Ví dụ 30. Tạo một Sequence
<rdf:RDF
xmlns:rdf=""
xmlns:tapi=""
xml:base=""
xmlns:mashup="">
[Technorati] Tag results for Movies
Sun, 30 Jul 2006 11:38:42 PST
<tapi:Inboundlinks
rdf:datatype="">
321580
<rdf:li rdf:resource="
review-lady-in-the-water/"/>
<rdf:li
rdf:resource=""/>
...
Về mặt chức năng, một rdf:Sequence thì tương tự như một rdf:Bag, nhưng khi sử
dụng thì trình tự lại quan trọng. Cần chú ý rằng không có gì về bản thân RDF tạo
nên sự khác biệt. RDF đơn giản là một cách thức được thỏa thuận trước để đánh
dấu thông tin; bản thân trình ứng dụng cần buộc phải theo trình tự đã được duy trì.
Một gợi ý là sự xuất hiện của các quan hệ một nhiều là khi một và chỉ một phần tử
trong một nhóm áp dụng. Ví dụ, bạn có thể có một tập hợp các mục theo đặc điểm
mà từ đó trình ứng dụng của bạn chọn một trong số đó để thể hiện (xem Ví dụ 31):
Ví dụ 31. Sử dụng rdf:Alt
...
<rdf:li
rdf:resource=""/>
<rdf:li
rdf:resource="
review-lady-in-the-water/"/>
<rdf:li
rdf:resource=""/>
...
Cú pháp tương tự như rdf:Bag và rdf:Alt, nhưng trong trường hợp này trình ứng
dụng – cần nhớ đó là trách nhiệm của trình ứng dụng! – cần phải chọn một và chỉ
một trong số các mục đã lựa chọn.
Các tập hợp
Bây giờ, cần nhớ là tôi đã nói về cách mà bạn có thể mô tả một nguồn đơn nhất sử
dụng nhiều thành tố rdf:Description? Trong trường hợp đó, tất cả thông tin được
tập hợp lại với nhau trong một nguồn đơn nhất. Điều này nghĩa là nếu chúng ta
xác định Bag (hoặc Sequence (Seq) hoặc Thay thế (Alt)) lần hai rdf: Description
có thể bổ sung các mục vào đó. Để ngăn chặn vấn đề này, bạn có thể xác định một
nhóm như một Tập hợp (xem Ví dụ 32):
Ví dụ 32. Sử dụng các Tập hợp
...
<rdf:Description
rdf:about="
review-lady-in-the-water/"/>
<rdf:Description rdf:about=
""/>
<rdf:Description rdf:about=
""/>
...
Trong trường hợp này, bạn xác định các nguồn cụ thể mà thuộc về Tập hợp và
đánh dấu nó bằng thuộc tính rdf:parseType.
RDF xác định hai hoặc các giá trị khác parseType. Bạn có thể sử dụng giá trị
Resource, như một cách khác để tạo các nốt rỗng, cũng giống như bạn dùng
nodeID từ trước đó, và bạn có thể dùng giá trị Literal để tạo một thành tố mà gồm
các thông tin XML ngữ pháp. Ví dụ, bạn có thể sử dụng nó để cho phép một Tóm
tắt để trình diễn XHTML, hoặc để gồm cả các mẫu XML mà bạn đã sử dụng trong
Phần 1 của loạt bài này (xem Tài nguyên).
Lược đồ RDF
RDF mô tả cách thức để xác định thông tin về một nguồn, nhưng bản thân thông
tin không có ý nghĩa. Để xác định loại của các mục và quan hệ của chúng – ví dụ
như các lớp và các lớp con – bạn cần bổ sung một số vào từ vựng của bạn. Những
bổ sung đó được đóng gói trong lược đồ RDF. Lược đồ RDF(hoặc được biết tới
như các RDF) có không gian tên của riêng nó và một số các thành tố và thuộc tính
đã được xác định. Trong phần này, tôi xem bạn sẽ cần phải tạo ra các lớp và các
đối tượng và quan hệ giữa chúng.
Tạo các lớp
Bước đầu tiền khi xác định một từ vựng là tạo các lớp. Giống như các lớp trong
một ngôn ngữ hướng đối tượng, các lớp RDF cung cấp một loại mẫu mà từ đó bạn
có thể tạo các đối tượng, hoặc như chúng được gọi theo cách khác trong RDF là
các cá thể. Để bắt đầu, cần tạo một số các lớp liên quan tới dịch vụ của bạn (xem
Ví dụ 33):
Ví dụ 33. Các lớp cơ bản
<rdf:RDF
xmlns:rdf="
rdf-syntax-ns#"
xmlns:rdfs="
schema#"
xml:base="">
<rdf:type
rdf:resource="
schema#Class"/>
<rdf:type
rdf:resource="
schema#Class"/>
<rdf:type
rdf:resource="
schema#Class"/>
<rdf:type
rdf:resource="
schema#Class"/>
Trong trường hợp này, bạn đã tạo ra bốn lớp. Bạn biết chúng là các lớp bởi vì bạn
đã thấy chúng được đánh dấu với một loại của
schema#Class. (Vì vậy bạn có thể sử dụng rdfs:class hơn là rdf:Description.)
Tạo các lớp con
Khi bạn xác định các lớp, bạn có thể tạo ra cá quan hệ giữa chúng. Bạn có thể làm
được điều đó với rdfs:subclass của đặc tính (xem Ví dụ 34):
Ví dụ 34. Tạo các lớp con
<rdf:RDF
xmlns:rdf=""
xmlns:rdfs=""
xml:base="">
<rdf:type rdf:resource=
""/>
<rdf:type rdf:resource=
""/>
<rdf:type rdf:resource=
""/>
<rdf:type rdf:resource=
""/>
Ở đây bạn đã xác định các lớp SOAPService và RESTService như các lớp con của
Service, và RSSFeed như một lớp con của RESTService. Điều đó nghĩa là nếu bạn
xác định một cá thể như một RSSFeed, bạn biết đó cũng là một RESTService và
một Service.
Tạo một ví dụ
Giờ bạn có các lớp, vậy làm cách nào để bạn tạo cá cá thể, tương tự các đối tượng
trong một ngôn ngữ hướng đối tượng?
Hãy thực hiện giống như cách bạn đã tạo các nguồn từ nhiều nơi trước đó, sự khác
biệt ở đây là bạn xác định các loại dựa trên các lớp mà bạn đã tạo ra (xem Ví dụ
35):
Ví dụ 35. Tạo các cá thể
<rdf:RDF
xmlns:rdf=""
xmlns:rdfs=""
xmlns:mashup=""
xml:base="">
<rdf:type rdf:resource=
""/>
<rdf:type rdf:resource=
""/>
<rdf:type rdf:resource=
""/>
Trong trường hợp này, hãy chú ý các không gian tên. Bạn đã xác định tiền tố
mashup: để kết hợp không gian tên cơ bản đã được sử dụng trong các định nghĩa,
và đã xác định không gian tên cơ bản mới.
Bạn đã tạo hai cá thể, Google và Amazon, và đã gán chúng với các loại. Cần lưu ý
rằng dịch vụ của Amazon, dịch vụ mà chấp nhận cả hai yêu cầu REST và SOAP,
thực ra có hai loại. Điều đó nghĩa là nó có các đặc tính được gán cho cả hai lớp.
Cũng cần lưu ý rằng bạn có thể tiếp tục và đơn giản hóa mã này bằng cách sử
dụng định dạng thay thế, khi ma bạn sử dụng tên loại như tên thành tố (xem Ví dụ
36):
Ví dụ 36. Đơn giản hóa trình bày
<rdf:RDF
xmlns:rdf=""
xmlns:rdfs=""
xmlns:mashup=""
xml:base="">
<rdf:type rdf:resource=
""/>
</mashup:RESTService
Cần lưu ý rằng bạn có thể vẫn xác định nhiều lớp, nhưng bạn chỉ cần lưu ý lớp thứ
hai. Bây giờ hãy xem cách thức thêm đặc tính vào các lớp này.
Tạo các đặc tính
Trong một ngôn ngữ hướng đối tượng, bạn chỉ cần tạo các đặc tính trong ngữ cảnh
của lớp đó. Tuy nhiên trong các RDF, bạn đã tạo các đặc tính của riêng chúng và
gán chúng vào các lớp (xem Ví dụ 37):
Ví dụ 37. Tạo các đặc tính
<rdf:RDF
xmlns:rdf=""
xmlns:rdfs=""
xml:base="">
<rdf:type rdf:resource=
""/>
<rdf:type rdf:resource=
""/>
<rdf:type rdf:resource=
""/>
<rdf:type rdf:resource=
""/>
<rdfs:range rdf:resource=
""/>
<rdfs:range rdf:resource=
""/>
Ở đây bạn đã tạo hai đặc tính, baseUrl và endpoint, và đã xác định miền và dãy
của chúng. Miễn là loại của nguồn trong đó đặc tính có thể xuất hiện, và dãy là
loại của dữ liệu mà nó có thể nắm giữ.
Miền quan trọng hơn mức mà bạn có thể nhận thấy do bởi bạn có thể sử dụng nó
khi lập luận. Ví dụ, bạn biết một đặc tính điểm cuối chỉ có thể xuất hiện trên một
SOAPService, vì vậy nếu một cá thể có điểm cuối, bạn biết đó là một
SOAPService, thậm chí nếu nó không được đánh dấu theo cách đó. Về sau này khi
bạn bắt đầu xem xét các bản thể luận và gán các dịch vụ và dữ liệu của chúng vào
các lớp, và ra các quyết định, khả năng này để lập luận sẽ trở nên quan trọng.
Sử dụng các đặc tính con
Cũng như bạn có thể tạo các lớp con để tạo ra các đặc tả của một lớp, bạn có thể
tạo các đặc tính con để tạo ra các đặc tả của một đặc tính. Xem Ví dụ 38:
Ví dụ 38. Tạo các đặc tính con
<rdf:RDF
xmlns:rdf=""
xmlns:rdfs=""
xml:base="">
<rdf:type rdf:resource=
""/>
<rdf:type rdf:resource=
""/>
<rdf:type rdf:resource=
""/>
<rdf:type rdf:resource=
""/>
<rdfs:range rdf:resource=
""/>
<rdfs:range rdf:resource=
""/>
Trong Ví dụ 38, bạn đã tạo ra một đặc tính chung, accessUrl, và xác định Url cơ
bản và các đặc tính của điểm cuối giống như các đặc tả của đặc tính đó. Điều này
nghĩa là nếu bạn tạo accessUrl như một nguồn thì bất cứ đặc tính nào mà bạn gán
cho nó cũng sẽ dùng được cho các đặc tính con.
Tóm tắt
Tóm tắt và tìm hiểu tiếp
Tại điểm này tôi đã trao đổi về Khung Mô tả Tài nguyên (RDF), RDF cung cấp
một cách thức chuẩn mực để mô tả các đặc tính cho các nguồn khác nhau. Những
đặc tính này bản thân chúng có thể là các nguồn, và bản thân chúng có thể có các
đặc tính. Bạn đã thấy cách thức để tạo các nguồn mới và tham chiếu chúng từ các
tài liệu và các không gian tên khác. Bạn cũng đã xem lược đồ RDF là cái cho phép
bạn tạo các lớp và quan hệ giữa chúng với nhau.
Điều này nghĩa là bạn đã sẵn sàng phát triển một bản thể luận cho hệ thống
mashup của bạn, và xác định nó bằng cách sử dụng Ngôn ngữ Bản thể luận Web
(OWL).
Các file đính kèm theo tài liệu này:
- Ultimate mashup – Các dịch vụ Web và Web ngữ nghĩa (semantic Web), Phần 3- Hiểu về RDF và ngôn ngữ _.pdf