CHƢƠNG 1 NGHIÊN CỨU TỔNG QUAN
1.2. RDF – NỀN TẢNG CỦA WEB NGỮ NGHĨA
1.2.6. Kiểu dữ liệu có cấu trúc
Mọi thứ sẽ rất đơn giản nếu chỉ những loại thông tin đƣợc ghi nhận về mọi thứ một cách rõ ràng trong định dạng của những phát biểu RDF đơn giản đã đƣợc minh họa từ trƣớc tới giờ. Tuy nhiên, hầu hết dữ liệu thế giới thực bao gồm những cấu trúc mà phức tạp hơn đó. Ví dụ, trong ví dụ ban đầu, ngày tạo trang web đƣợc ghi nhận nhƣ một thuộc tính exterms:creation-date
đơn với một Plain Literal nhƣ giá trị của nó. Tuy nhiên, giả sử giá trị của thuộc tính exterms:creation-date cần đƣợc ghi ngày, tháng, năm thành những mẫu thông tin tách biệt thì chúng đƣợc viết nhƣ thế nào hay trong trƣờng hợp thông tin cá nhân của John Smith, giả sử địa chỉ của John đƣợc mô tả, cả điạ chỉ có thể đƣợc viết nhƣ một Plain Literal, nhƣ trong bộ ba:
exstaff:85740 exterms:address "1501 Grant Avenue, Bedford, Massachusetts 01730" .
Tuy nhiên, giả sử địa chỉ của John cần thiết để ghi nhận nhƣ một cấu trúc bao gồm những giá trị nhƣ: tên đƣờng phố, thành phố, bang … thì điều này sẽ đƣợc viết trong RDF nhƣ thế nào ? Thơng tin có cấu trúc đƣợc biểu diễn trong RDF bằng cách coi tồn bộ mọi thứ đƣợc mơ tả (nhƣ địa chỉ của John Smith) nhƣ một tài nguyên, và tạo ra những phát biểu về tài nguyên mới. Vì vậy, trong đồ thị RDF, để chia nhỏ địa chỉ của John Smith thành những thành phần của nó, một nút mới đƣợc tạo ra để biểu diễn khái niệm địa chỉ của John Smith, với một URI mới để xác định nó
http://www.example.org/addressid/85740, (đƣợc rút gọn thành
chủ ngữ, để biểu diễn thông tin bổ sung, tạo ra đồ thị biểu diễn ở hình 1.4:
Hình 1.4. Mơ tả việc chia nhỏ giá trị một thuộc tính
Hay những bộ ba:
exstaff:85740 exterms:address exaddressid:85740 . exaddressid:85740 exterms:street "1501 Grant Avenue" . exaddressid:85740 exterms:city "Bedford" .
exaddressid:85740 exterms:state "Massachusetts" . exaddressid:85740 exterms:postalCode "01730" .
Cách biểu diễn thơng tin có cấu trúc này trong RDF có thể kéo theo việc tạo ra vô số những URI trung gian nhƣ exaddressid:85740 để biểu diễn tòan bộ những khái niệm nhƣ địa chỉ của John Smith. Nhiều khái niệm có thể khơng bao giờ cần thiết đƣợc đề cập tới một cách trực tiếp từ bên ngoài của một đồ thị đặc biệt, và vì vậy khơng thể yêu cầu những định danh toàn cục. Ngoài ra, trong bản vẽ của đồ thị biểu diễn nhóm những phát biểu trong hình 1.5, URI gán vào để xác định địa chỉ của John Smith không thật sự cần thiết, từ đó đồ thị có thể đƣợc vẽ dễ dàng nhƣ trong hình 1.5:
Hình 1.5. Sử dụng nút rỗng
Hình 1.5 là một đồ thị RDF sử dụng một nút mà khơng có một URI để đại diện cho địa chỉ của John Smith. Nút rỗng này cung cấp những kết nối cần thiết tới những thành phần khác của đồ thị. Nút trống cũng đƣợc gọi là tài nguyên vô danh. Tuy nhiên, một định danh rõ ràng cho nút trống đó rất cần thiết để biểu diễn đồ thị này nhƣ những bộ ba. Để thấy điều này, hãy cố gắng viết những bộ ba tƣơng ứng với những gì vẽ trong hình 1.6 sẽ tạo ra một cái gì đó nhƣ:
exstaff:85740 exterms:address ??? .
??? exterms:street "1501 Grant Avenue" . ??? exterms:city "Bedford" .
??? exterms:state "Massachusetts" . ??? exterms:postalCode "01730" .
Trong đó ??? đại diện cho bất cứ cái gì mà biểu diễn sự có mặt của nút trống. Từ đó một đồ thị phức tạp có thể có nhiều hơn một nút rỗng, cũng cần có một cách để phân biệt nút trống này với nút trống khác trong một sự biểu diễn bộ ba của đồ thị. Kết quả là, những bộ ba sử dụng những định danh nút rỗng, có dạng _:name để chỉ thị sự hiện diện của nút trống. Ví dụ, trong ví dụ
này một định danh nút rỗng _:johnaddress có thể đƣợc dùng để đề cập đến nút rỗng, mà trong trƣờng hợp này những bộ ba có thể là:
exstaff:85740 exterms:address _:johnaddress .
_:johnaddress exterms:street "1501 Grant Avenue" . _:johnaddress exterms:city "Bedford" .
_:johnaddress exterms:state "Massachusetts" . _:johnaddress exterms:postalCode "01730" .
Trong việc biểu diễn những bộ ba của một đồ thị, mỗi nút rỗng riêng biệt trong đồ thị đƣợc cho một định danh nút rỗng khác nhau. Không nhƣ những URI và những Literal, những định danh nút rỗng không đƣợc coi là những thành phần thực sự của đồ thị RDF (điều này có thể thấy rõ bằng cách nhìn vào đồ thị ở hình 1.6 và để ý nút rỗng khơng có định danh cho nó). Những định danh nút rỗng chỉ là một cách để thể hiện nó trong một đồ thị và phân biệt nó với nút rỗng khác khi đồ thị đƣợc viết ở định dạng bộ ba. Những định danh nút rỗng cũng chỉ quan trọng trong những bộ ba biểu diễn một đồ thị đơn (hai đồ thị khác nhau với cùng số những nút rỗng có thể sử dụng độc lập những định danh nút rỗng để phân biệt chúng, và điều đó khơng đúng khi cho rằng những nút rỗng từ những đồ thị khác nhau có cùng những định danh nút rỗng thì nhƣ nhau). Nếu một nút trong đồ thị cần đƣợc tham chiếu từ đồ thị bên ngồi, thì một URI có thể đƣợc gán để xác định nó. Sau cùng, bởi vì những định danh nút rỗng biểu thị những nút rỗng hơn là biểu thị các cung trong định dạng bộ ba của một đồ thị RDF, những định danh nút rỗng có thể chỉ xuất hiện nhƣ chủ ngữ hay tân ngữ trong những bộ ba; định danh nút rỗng không thể là vị từ trong bộ ba.
Ở phần mở đầu của phần này đã chú ý rằng toàn bộ những cấu trúc, nhƣ địa chỉ của John Smith có thể đƣợc biểu diễn bằng cách coi những điều này đƣợc mô tả nhƣ một tài nguyên riêng biệt, và sau đó tạo ra những phát
biểu về những tài nguyên mới này. Ví dụ này minh họa một khía cạnh quan trọng của RDF: RDF chỉ biểu diễn trực tiếp những quan hệ nhị phân, ví dụ: quan hệ giữa John và Literal thể hiện địa chỉ của anh ta. Việc biểu diễn mối quan hệ John và nhóm những thành phần tách biệt của địa chỉ này kéo theo làm việc với n cách quan hệ (trong trƣờng hợp này là 5) giữa John và tên đƣờng phố, thành phố, bang và những thành phần mã vùng. Để biểu diễn nhƣ những cấu trúc một cách trực tiếp trong RDF thì quan hệ n cách phải chia nhỏ vào thành một nhóm những quan hệ nhị phân tách biệt. Những nút rỗng tạo ra một cách thức để làm đƣợc điều này. Đối với mỗi quan hệ n cách này một trong những thành phần tham gia đƣợc chọn nhƣ chủ ngữ của quan hệ (trong trƣờng hợp này là John), một nút rỗng đƣợc tạo ra để biểu diễn phần còn lại của quan hệ (địa chỉ của John). Những thành phần tham gia cịn lại trong quan hệ (nhƣ thành phố) sau đó đƣợc biểu diễn nhƣ những thuộc tính riêng biệt của tài nguyên mới thể hiện bởi nút rỗng.
Những nút rỗng cũng cung cấp một cách thức để tạo ra những phát biểu chính xác hơn mà khơng có những URI, nhƣng chúng đƣợc mô tả dƣới dạng quan hệ với tài nguyên khác để làm cho chúng có URI. Ví dụ, khi tạo những phát biểu về một ngƣời, nhƣ Jane Smith, điều đó rất bình thƣờng để sử dụng một URI dựa vào điạ chỉ email của ngƣời đó nhƣ URI của ngƣời đó, ví dụ:
mailto:jane@example.org. Tuy nhiên, phƣơng pháp này có thể dẫn đến một
số vấn đề. Ví dụ, khi cần thiết để ghi lại thơng tin về hộp thƣ của Jane cũng nhƣ về chính Jane và sử dụng một URI cho Jane dựa vào địa chỉ mail của cô ấy dẫn đến những khó khăn khi muốn biết xem Jane hay hộp thƣ mail của cô ấy đƣợc mô tả. Vấn đề tƣơng tự tồn tại khi một URL trang web của một công ty http://www.example.com/ đƣợc sử dụng nhƣ URI của chính cơng ty. Một
lần nữa, thật sự cần thiết để ghi nhận thơng tin về chính trang web (ví dụ: ngƣời tạo ra trang web và đƣợc tạo khi nào) cũng nhƣ về công ty, và sử dụng
http://www.example.com/ nhƣ một định danh dẫn đến việc rất khó biết trong
số những cái đó cái nào là chủ ngữ thực sự.
Vấn đề cơ bản là với việc sử dụng hộp thƣ mail của Jane nhƣ một đại diện cho Jane khơng thực sự chính xác: Jane và hộp thƣ mail của cơ ấy thì khơng giống nhau, và vì vậy chúng nên đƣợc xác định khác nhau. Khi chính Jane khơng có một URI, một nút rỗng tạo ra cách chính xác hơn của mơ hình trong tình huống này. Jane có thể đƣợc biểu diễn nhƣ một nút rỗng, và nút rỗng đó đƣợc dùng nhƣ chủ ngữ của một phát biểu với exterms:mailbox nhƣ thuộc tính và URI mailto:jane@example.org nhƣ giá trị của thuộc tính đó. Nút rỗng này cũng có thể đƣợc mơ tả với một thuộc tính rdf:type có giá trị exterms:Person, thuộc tính exterms:name có giá trị ―John Smith‖, và một số
khác mơ tả thơng tin rất có lợi, nhƣ biểu diễn trong những bộ ba sau:
_:jane exterms:mailbox <mailto:jane@example.org> . _:jane rdf:type exterms:Person .
_:jane exterms:name "Jane Smith" . _:jane exterms:empID "23748" . _:jane exterms:age "26" .
Để ý rằng mailto:jane@example.org đƣợc viết trong dấu ―< >‖ trong
bộ ba đầu tiên, bởi vì mailto:jane@example.org là một URI đầy đủ trong lƣợc đồ URI mailto, hơn là một dạng rút gọn QName, và những URI đầy đủ phải đƣợc đặt trong dấu ―< >‖ trong các định dạng bộ ba.
Điều này chỉ rõ rằng có một tài nguyên thuộc kiểu exterms:Person, mà
hộp thƣ mail của ngƣời nào đƣợc xác định bởi mailto:jane@example.org thì
tên ngƣời đó là Jane Smith. Nghĩa là, nút rỗng có thể đọc nhƣ ―có một tài nguyên‖. Những phát biểu với nút rỗng là chủ ngữ cung cấp thông tin về đặc trƣng của tài nguyên.
trƣờng hợp nhƣ thế này không làm thay đổi cách mà loại thông tin này đƣợc xử lý nhiều. Ví dụ, nếu một điạ chỉ email xác định duy nhất ngƣời nào đó tại
example.org thì địa chỉ đó có thể vẫn đƣợc dùng để kết hợp thơng tin về
ngƣời đó từ nhiều tài ngun, thậm chí khi điạ chỉ email khơng là URI của ngƣời đó. Trong trƣờng hợp này, nếu một vài RDF đƣợc tìm thấy trên web mơ tả về một cuốn sách và đƣa thông tin liên lạc của tác giả nhƣ
mailto:jane@example.org, thì điều đó có thể hợp lý, việc kết hợp thơng tin
mới này với tập những bộ ba trƣớc kết luận rằng tên của tác giả là Jane Smith. Vấn đề là điều đó nói rằng bất cứ thứ gì đó nhƣ ―tác giả của cuốn sách là
mailto:jane@example.org” là một cách rút gọn của ―tác giả của cuốn sách là
bất kì ai ngƣời mà có hộp thƣ mail là mailto:jane@example.org‖. Việc sử
dụng một nút rỗng để biểu diễn ―bất kì ai này‖ chỉ là một cách chính xác để biểu diễn trong tình huống thế giới thực.
Sử dụng nút rỗng theo cách này cũng giúp tránh sử dụng những Literal trong những tình huống khơng thích hợp. Ví dụ, trong mơ tả cuốn sách của Jane, thiếu một URI để xác định tác giả, ngƣời xuất bản có thể viết (sử dụng từ vựng riêng ex2terms: của ngƣời xuất bản):
ex2terms:book78354 rdf:type ex2terms:Book . ex2terms:book78354 ex2terms:author "Jane Smith" .
Tuy nhiên, tác giả cuốn sách thực ra khơng phải là chuỗi kí tự ―Jane Smith‖, nhƣng một ngƣời mà tên của ngƣời đó là Jane Smith. Thông tin tƣơng tự có thể chính xác hơn cho ngƣời xuất bản sử dụng một nút rỗng nhƣ:
ex2terms:book78354 rdf:type ex2terms:Book . ex2terms:book78354 ex2terms:author _:author78354 . _:author78354 rdf:type ex2terms:Person . _:author78354 ex2terms:name "Jane Smith" .
loại ex2terms:Book và tác giả là một tài nguyên thuộc loại ex2terms:Person,
tên tác giả là Jane Smith‖. Tất nhiên, trong trƣờng hợp đặc biệt này ngừơi xuất bản có thể thay việc gán URI riêng của nó để tác giả của nó thay thế việc sử dụng những nút rỗng để xác định chúng, để giúp những tham chiếu bên ngoài tới tác giả của nó.
Cuối cùng, ví dụ trên cho biết tuổi của Jane là 26 chứng tỏ rằng đôi khi giá trị của thuộc tính có thể xuất hiện ở dạng đơn giản, nhƣng cũng có thể phức tạp. Trong trƣờng hợp này, tuổi của Jane thực sự là 26 years, nhƣng thông tin đơn vị years không thể hiện rõ. Thông tin nhƣ thế này thƣờng đƣợc bỏ đi trong những phạm vi mà điều đó có thể an tồn để mọi ngƣời truy cập giá trị thuộc tính sẽ hiểu những đơn vị đƣợc dùng. Tuy nhiên, trong phạm vi rộng hơn của web, thơng thƣờng điều đó khơng an tồn để đƣa ra giả định này. Ví dụ, một trang web ở Mỹ có đơn vị đo lƣờng là pound, nhƣng bất kỳ ai truy cập dữ liệu đó ở bên ngồi nƣớc Mỹ (Việt Nam) có thể cho rằng đơn vị đó là kilogram. Thông thƣờng, chúng ta nên xem xét cẩn thận để đƣa ra những đơn vị đại diện và những thông tin tƣơng tự.