Kiểu dữ liệu có cấu trúc

Một phần của tài liệu 28063_1712202001934183LVPhamHuuThang (Trang 30 - 37)

8. Bố cục của luận văn

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 toà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 exaddressid:85740). Những phát biểu RDF có thể được viết với nút đó 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 toàn 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.4, 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.5 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.

để đề 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.5 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 ngoà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à

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ệ nhiều 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

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:Nguoi, 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:Nguoi .

_: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:Nguoi, 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.

Thực ra, việc sử dụng nút rỗng thay cho những URI trong những 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 nguyên, 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:Nguoi . _:author78354 ex2terms:name "Jane Smith" .

Về cơ bản điều này nói rằng tài nguyên ex2terms:book78354 thuộc loại

ex2terms:Book và tác giả là một tài nguyên thuộc loại ex2terms:Nguoi, 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 toà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 toà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 ngoà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ự.

Một phần của tài liệu 28063_1712202001934183LVPhamHuuThang (Trang 30 - 37)