Chứng khoán “câu giờ” chờ động thái mới của UBCK?

Bằng một loạt các chính sách điều chỉnh, nỗ lực từ phía UBCK nhằm “cứu” chứng khoán xem ra đang rất khả dĩ, đơn giản vì NĐT không còn cảm thấy “đau đầu” khi CK liên tục rớt sàn. Biện pháp giảm biên độ giao động, đồng thời kêu gọi các ngân hàng ngừng việc giải chấp các hợp đồng cầm cố, các REPO chứng khoán (tức là các hợp đồng mua bán chứng khoán có kỳ hạn)… đã phần nào ổn định được tâm lý đang vô cùng hoang mang của các NĐT. Tức là UBCK chưa phải viện đến chiêu thức đóng cửa TTCK.

“Màu xanh” đã trở lại, nhưng thực chất, VN-Index chỉ “nhích” lên 3-4 điểm mỗi phiên. Với “tốc độ” kiểu này còn lâu mới đạt được ngưỡng 600, đừng nói gì là cái mốc 900 vốn được nhiều người dự đoán là cái mốc lý tưởng. Rõ ràng, những NĐT không trông đợi vào cái kiểu “ổn định” như thế. CK Việt gần đây liên tục gặp những tình huống dở khóc dở cười, “lúc bán không ai mua”, “lúc mua không ai bán”. Với cảnh mua bán một chiều như thế này thì CK cần có những đợt “sóng” và với cơ chế như hiện tại thì khó lòng mà đạt được điều mong mỏi ấy. Nhưng để như vậy thì biên độ dao động phải được trở lại trạng thái 5% (HOSE) và 10% (HASTC) thay vì 1% và 2% như hiện tại. Vấn đề là bao giờ? Khi mà việc giải chấp các hợp đồng cầm cố, các REPO chứng khoán trước sau gì cũng phải được thực hiện.

Kinh nghiệm từ đợt rớt sàn “lập đáy” mới trước cho thấy, chỉ sau 3 phiên tăng trần, các NĐT lướt sóng lập tức bán tống bán tháo ngay đi các CP bởi lợi nhuận mà họ kiếm được đã ở mức 10-15% – một con số có thể làm hài lòng bất kỳ NĐT nào. Và hệ lụy là CK trở lại với “quỹ đạo rơi tự do” và liên tục phá đáy xuống dưới 500 điểm. Rất có thể lịch sử sẽ lập lại bởi lợi nhuận 3-5% cũng không quá tồi. Và sau đó…

Các chính sách hiện tại có vẻ như đang “kéo giò” nhau chỉ để chờ những động thái tích cực mới từ phía UBCK song với cá nhân của một kẻ “ngoại đạo” như tôi thì tôi vẫn mong cái biện pháp giảm biên độ dao động sẽ diễn ra trễ hơn thời điểm 27/03 hoặc trong tình thế này nó sẽ kết thúc sớm hơn việc thực hiện giải chấp của các ngân hàng (chắc chắn là vậy nhưng là bao giờ). Và liệu có khi nào, CK áp dụng biên độ dao động khác nhau cho những ngày khác nhau không nhỉ? Chẳng hạn như biên độ 5% đối với thứ 3, còn lại là 1%… Hay là giờ đang đà tăng, cứ khôi phục lại biên độ cũ, khi nào giảm lại hạ biên độ!!! Đó cũng chỉ là những biện pháp tình thế mang tính chất chắp vá cho đến khi TTCK đạt tới “trạng thái lý tưởng”. Đó chỉ là cái nhìn bi quan!

Trở lại với cái nhìn lạc quan, giá CP đã xuống tới mức “vô lý”, do đó, việc mua vào lúc này sẽ trở nên không thể “hợp lý” hơn. Kết quả là, rất có thể, đây chính là cú “hích” giúp CK trở lại đà tăng trưởng.

Và dù thế nào đi nữa, trở lại vấn đề đã đặt ra, cái biện pháp giảm biên độ dao động đến hồi sẽ phải được tháo dỡ! Khả năng sẽ là đầu tháng 4. Nhưng mong là đừng có trúng ngày 1/4 vì lúc đó không biết nên tin ai đâu đấy!

7 lưu ý khi thiết kế web với CSS và HTML!

  1. Không sử dụng các thẻ HTML nhằm mục đích định dạng hay trình bày nội dung. Hãy nhớ rằng, các thẻ HTML chỉ phục vụ cho việc đánh dấu tài liệu, còn các thuộc tính của CSS mới được dùng cho việc định dạng nội dung.
  2. Không chèn các đoạn mã css vào bên trong tài liệu HTML. Để thực hiện công việc này hãy sử dụng các class.
  3. Hãy định nghĩa các đặc tính định dạng thường dùng một lần duy nhất.
  4. Bạn hoàn toàn có thể áp dụng nhiều class cho một một HTML element.
  5. Sử dụng selector hierarchical thay cho việc mở rộng thêm các class.
  6. Hãy Sử dụng external style sheet. Chỉ sử dụng internal style sheet trong trường hợp bạn muốn có những ngoại lệ riêng cho một trang HTML nào đó.
  7. Nếu cần, hãy chia nhỏ file .css thành nhiều file tùy theo ý đồ thiết kế hoặc thói quen, miễn là hợp lý và logic.

Web Standards

Hôm nay trong lớp lại nghe tới chuyện việc hiển thị web ở mỗi trình duyệt mỗi khác, IE khác, Firefox khác, Safari lại càng khác… mình lại nghĩ tới Web Standards. Cũng chẳng mới mẻ gì, khái niệm này mình cũng nghe lâu rồi, và cũng cố gắng áp dụng, à không tuân thủ mỗi khi “làm web” – dùng từ “làm” thay cho “design” bởi lẽ mình thấy những gì mình làm ra chưa thể gọi là “nghệ thuật”, mà không phải là “nghệ thuật” – sao có thể gọi là design.

Web Standards

Dù bạn đã từng làm công việc phát triển một ứng dụng web hay chỉ là những người mới tiếp cận công việc đầy thú vị này, thì Web Standard vẫn thật sự là một vấn đề bạn cần lưu tâm. Nó sẽ giúp bạn có được một “ấn phẩm web” có “chất lượng”, hoạt động ổn định trên hầu hết các trình duyệt web thông dụng, bạn sẽ không còn lo lắng quá nhiều về vấn đề người dùng sẽ dùng trình duyệt nào, hệ điều hành nào…. để sử dụng ứng dụng web mà bạn đã tạo ra. Thông thường thì việc phát triển các ứng dụng web “tương thích” với nhiều trình duyệt… sẽ phát sinh thêm những dòng code để phát hiện người dùng đang sử dụng trình duyệt nào và ứng với mỗi trình duyệt như thế sẽ có những xử lý khác nhau, tăng số lượng dòng code đồng nghĩa với chi phí phải trả cho nhân viên sẽ cao hơn. Tuy nhiên, do vấn đề lợi nhuận nên công việc đó thường bị xem nhẹ, thậm chí bỏ đi. Hậu quả là một phần nội dung hoặc những thao tác như ý đồ thiết kế không được thực hiện. Chính vì vậy, việc tuân thủ Web Standard sẽ góp phần giảm thiểu chi phí cho việc phát triển một cách đáng kể. Thậm chí ứng dụng web của bạn còn có khả năng phục vụ cho nhiều đối tượng người dùng, đặc biệt là dành cho cả người khiếm thị.

Vậy thực chất Web Standards là gì? Web Standards là một tập hợp các tiêu chuẩn, chuẩn mực về công nghệ, ngôn ngữ… đảm bảo cho một trang web có thể hoạt động tốt trên mọi nền tảng phần mềm hay phần cứng. Không những vậy, nó còn hạn chế được chi phí phát sinh khi tiến hành phát triển, bảo trì trang web.

Vậy tuân thủ Web Standards sẽ đem lại lợi ích gì?

  • Trước mắt là vấn đề hiển thị. Mọi thứ sẽ tương đương nhau cho dù bạn dùng trình duyệt nào, hệ điều hành nào, trên PC, thiết bị PDA hay các điện thoại có chức năng duyệt web và thậm chí cả công tác in ấn nữa.
  • Tiếp theo dĩ nhiên là vấn đề lợi nhuận như đã phân tích ở trên.
  • Giải quyết được vấn đề cộng tác, bạn hình dung một ứng dụng web được phát triển bởi nhiều cá nhân có trình độ, tư duy, phương pháp tiếp cận khác nhau… chưa kể, công việc được chia thành nhiều công đoạn, quy trình phát triển khác nhau… do đó cần phải tạo ra những quy ước để các cá nhân có thể hợp tác “ổn thỏa” với nhau. Do đó, tốt nhất là sử dụng chuẩn
  • Một điều nữa đó là nó hứa hẹn ứng dụng web sẽ được thực thi nhanh hơn (dù chưa được kiểm chứng rõ ràng). Lý do có thể là do số lượng dòng code được giảm thiểu, trình duyệt không còn phải xử lý những đoạn code lạ do các kỹ thuật hack (như hack css) gây ra.

Tuân thủ Web Standards như thế nào? Đây thực sự là một câu hỏi hay! Trước khi nói về cách thức tuân thủ Web Standards chúng ta cần biết rằng, khi nói tới “Standard” là nói tới các ngôn ngữ được sử dụng trong Web Standards. Cụ thể là

  • Ngôn ngữ có cấu trúc và mang tính ngữ nghĩa (Structural and Semantic Languages): Đó chính là HTML 4.01, XHTML 1.0 và XML 1.0
  • Ngôn ngữ trình bày (Presentation Languages): Đó chính là CSS level 1, 2, 2. Ngôn ngữ này giúp chúng ta có thể dễ dàng và linh động trong việc định dạng màu sắc, kích thước, vị trí… của các thành phần trong ứng dụng web của bạn.
  • Mô hình đối tượng (Object Model): Đó là DOM level 1, 2, 3. Mô hình này cho phép chúng ta thao tác được với tất cả các đối tượng theo mô hình cây.
  • Ngôn ngữ kịch bản (Scripting Language): Đó chính là ECMAScript được biết với cái tên thông dụng là JavaScript dù rằng gọi như thế là không đầy đủ. Loại ngôn ngữ này thường được biết đến với việc tạo ra các hiệu ứng, các xử lý hoạt động tương tác ở phía client.
  • Ở một mức cao hơn, bạn nên biết đến phiên bản mở rộng của HTML và XHTML, các ngôn ngữ đánh dấu mở rộng như MathML. Tuy nhiên, tạm thời chúng ta chỉ cần quan tâm tới 4 loại ngôn ngữ ở trên là đủ.

Vậy là bạn đã đoán được ý đồ của việc tuân thủ Web Standards rồi đấy! Chỉ cần bạn sử dụng các ngôn ngữ trên cho các ứng dụng web của bạn một cách thành thục và cố gắng phát huy tối đa lợi thế mà mỗi ngôn ngữ trên đem lại. Tuy nhiên cần chú ý tới những yêu cầu đi kèm đối với việc sử dụng mỗi ngôn ngữ. Chẳng hạn như các quy định khi làm việc với XHTML đó là:

  • Có thẻ mở thì phải có thẻ đóng. Ví dụ: <html>…</html>
  • Đối với các loại thẻ rỗng (empty tags) như <br>, <hr>… được sử dụng dưới hình thức <br />, <hr /> hoặc có thẻ đóng </br>, </hr>..
  • Các giá trị của các thuộc tính phải được bao bởi cặp dấu nháy đơn hoặc nháy kép.
  • Thẻ mở trước phải được đóng sau. Tức là các thẻ có thể được lồng vào nhau nhưng không được chồng lên nhau. Ví dụ: <b><i>Hello World!</b></i> là không hợp lý. Phải là: <b><i>Hello World!</i></b>

Bạn đã phần nào thấy được sự tuyệt vời mà Web Standards đem lại, việc tuân thủ chúng có vẻ cũng đơn giản. Tuy nhiên, cũng như bất kỳ những vấn đề gì, việc tuân thủ Web Standards cũng có những mặt hạn chế và bất cập.

  • Đầu tiên, bạn sẽ phải thay đổi tư duy khi phát triển ứng dụng web. Một điều thường thấy là các trang web vẫn được thiết kế theo hướng table, nghĩa là bạn sử dụng table để trình bày bố cục (layout) của trang web. Tức là phần code HTML của trang web thường có dạng <body><table width=”100%”>…</table></body>… hoặc tương tự như thế. Cách thiết kế này gọi là “table-based”. Để thay thế nó, bạn nên biết và sử dụng cách thiết kế “boxed-model” mà bạn có thể tìm thấy nó trong bất cứ tài liệu nào về CSS. Còn vấn đề tại sao ư, việc layout cho trang web của bạn theo hướng table-based sẽ khiến trang web của bạn load chậm hơn, nó làm cho trang web của bạn mất đi tính “accessible”, tức là bạn không thể lướt web bằng bàn phím hoặc trên các thiết bị PDA, điện thoại chưa kể, bạn không thể tận dụng tối đa những điều tuyệt vời mà CSS đem lại, mà trong chừng mực của bài viết này không thể trình bày kỹ càng. Một cách đơn giản, hãy sử chúng vì nó là “chuẩn”.
  • Bạn phải học cách phân tách công việc trình bày và xử lý. Một cách nôm na đó là khi bạn muốn thay đổi định dạng màu sắc, kích thước của một phần tử, việc mà bạn cần làm đó là chỉnh sửa file CSS chứ không phải là chỉnh sửa các đoạn code xử lý.
  • Một bất lợi nữa đó là hiện nay các trình duyệt vẫn chưa có sự “ăn ý” với nhau. Giữa chúng vẫn còn một khoảng cách nhất định. Bạn hoàn toàn có thể nhận ra điều này khi ứng dụng boxed-model trên các trình duyệt IE và đem so sánh với Firefox, Nescape, Opera, Safari… Bạn sẽ nhận thấy rằng, chính IE mới là kẻ “tội đồ”. Vì vậy hãy sử dụng song song các trình duyệt.
  • Đó là chưa kể tới việc bạn phải tốn công nghiên cứu Web Standard là cái gì nữa đó! Nhưng đừng quá lo lắng, mọi thứ khi mới bắt đầu đều gặp khó khăn cả. Dần dần, bạn sẽ thấy những điều tuyệt vời mà Web Standards đem lại.

Bạn đã từng quan tâm tới chất lượng sản phẩm liệu có đáp ứng được yêu cầu của bạn như hứa hẹn của nhà sản xuất, bạn đã từng quan tâm tới ISO của một sản phẩm, của một công ty, của một tổ chức; đã từng nghe tới CMMi của một công ty phần mềm… vậy hãy quan tâm tới Web Standard.

Describing Web Resource in RDF (Chapter III – Part II)

Tiếp theo loạt bài về Semantic Web, chúng ta sẽ tìm hiều một số khái niệm liên quan được dùng trong RDF.

  • Tài nguyên (resource): Chúng ta có thể hiểu đơn giản rằng một tài nguyên cũng giống như một đối tượng, một vật mà chúng ta muốn đề cập. Tài nguyên có thể là tác giả, quyển sách, nhà xuất bản, nơi chốn, con người, khách sạn, các câu truy vấn tìm kiếm v.v… Mỗi tài nguyên có một URI (Universal Resource Indentifier). Một URI có thể là một URL (Unified Resource Locator) hoặc một loại giá trị định danh duy nhất nào đó. Lưu ý rằng, một định danh không nhất thiết phải cho phép truy cập tới tài nguyên. URI đã được định nghĩa không chỉ cho địa chỉ web mà còn cho các đối tượng khác số điện thoại, số ISBN hay các vị trí địa lý. Thậm chí đã có nhiều cuộc tranh luận về bản chất của URI cả về phương diện triết học, chẳng hạn như cái gì “định danh duy nhất” một con người…, trong khuôn khổ của bài viết, chúng ta chỉ giả định rằng URI định danh một tài nguyên web.
  • Thuộc tính (Property): Thuộc tính là loại tài nguyên; chúng mô tả mối quan hệ giữa các tài nguyên, chẳng hạn như “written by”, “age”… Thuộc tính trong RDF cũng được xác định bởi URI (thường là URL). Ý tưởng dùng URI để xác định một vật và mối quan hệ giữa chúng là khá quan trọng. Nó cho phép chúng ta có cùng một mô hình đặt tên, do đó, giảm thiểu được những tình huống trùng tên vốn gây ra nhiều phiền toái đối với việc biểu diễn dữ liệu.
  • Phát biểu (Statement): Một phát biểu xác định thuộc tính cho tài nguyên. Một phát biểu là một bộ ba object-attribute-value gồm có một tài nguyên, một thuộc tính và một giá trị. Giá trị có thể là tài nguyên hoặc cũng có thể là giá trị kiểu chuỗi.
  • Biểu diễn một phát biểu: Giả sử, ta có một phát biểu sau:
  • David Billington is the owner of the Web page http://www.cit.gu.edu.au/~db

    Cách đơn giản để thể hiện phát biểu này đó là sử dụng định nghĩa về bộ ba object-attribute-value ở trên(”David Billington”, http://www.mydomain.org/site-owner, http://www.cit.gu.edu.au/~db)Chúng ta có thể xem bộ ba (x, P, y) như là một biểu thức logic P(x,y), trong đó mệnh đề P chỉ ra mối quan hệ giữa x và y. Thực ra RDF chỉ đưa ra mệnh đề.

    Figure 3-1

    Hình 3.1: Đồ thị biểu diễn bộ ba Để ý rằng thuộc tính “site-owner” và một trong hai đối tượng được xác định bởi URL, đối tượng còn lại được xác định bởi một chuỗi ký tự.Hình 3.1 biểu diễn đồ thị của phát biểu đã đưa ra. Nó là một đồ thị có hướng với các node có gắn nhãn và các cung; các cung được nối trực tiếp từ tài nguyên (chủ từ – subject trong phát biểu) tới giá trị (túc từ – object trong phát biểu). Trong Trí tuệ nhân tạo, loại đồ thị này được gọi là mạng ngữ nghĩa (semantic net). Như đã nói, giá trị được nêu ra trong một phát biểu có thể là một tài nguyên. Do đó, nó có thể được liên kết tới một tài nguyên khác như trong các triple sau:

    • (http://www.cit.gu.edu.au/~db, http://www.mydomain.org/site-owner, “David Billington”)
    • (”David Bilington”, http://www.mydomain.org/phone, “3875507″)
    • (”David Billington”, “http://www.mydomain.org/uses, http://www.cit.gu.edu.au/~arock/defeasible/Defeasible.cgi)
    • (”www.cit.gu.edu.au/~arock/defeasible/Defeasible.cgi”, http://www.mydomain.org/site-owner,”Andrew Roc”
Những triple đó được biểu diễn như sau
Figure 3-2

Đồ thị thật sự là công cụ mạnh mẽ để mô tả cho con người hiểu, nhưng mục đích của Semantic Web lại yêu cầu những hình thức biểu diễn mà máy tính có thể truy xuất và xử lý được.Do đó, có một hình thức biểu diễn đáp ứng được yêu cầu đó là dựa vào XML. Theo khả năng này, một tài liệu RDF được biểu diễn bởi một element của XML với thẻ là rdf:RDF. Phần nội dung của element này đó là số lượng các Diễn giải (Descriptions) dùng thẻ rdf:Description. Mỗi diễn giải như thế tạo nên một phát biểu về một tài nguyên, được xác định bằng một trong ba cách sau:

    • Thuộc tính about: tham chiếu tới một tài nguyên đã có
    • Thuộc tính ID : tạo ra một tài nguyên mới
    • Không có tên: tạo ra một tài nguyên nặc danh (anonymous )

Sau đây là ví dụ về cách thể hiện phát biểu đã đưa ra

Figure 3-3

Thành phần rdf:Description tạo ra một phát biểu về tài nguyên “http://www.cit.gu.edu.au/~db”. Trong đó, phần thuộc tính đóng vai trò như một thẻ, và phần nội dung là giá trị của thuộc tính đó. Việc mô tả đó tuân theo đúng một trật tự, nói cách khác cú pháp XML thiết lập một sự tuần tự (serialization). Thứ tự của các diễn giải (hay tài nguyên) thì không quan trọng mà tùy theo mô hình trừu tượng của RDF. Điều này một lần nữa cho thấy rằng, mô hình đồ thị là mô hình dữ liệu thực sự của RDF còn XML chỉ là hình thức biểu diễn cho đồ thị mà thôi.

Describing Web Resource in RDF (Chapter III – Part I)

  1. Giới thiệu

XML là siêu ngôn ngữ (metalanguage) thông dụng dành cho vệc định nghĩa markup. Nó cung cấp một framework chung và tập các công cụ như parsers dành cho việc trao đổi dữ liệu và các siêu dữ liệu (metadata) giữa các ứng dụng. Tuy nhiên, XML không cung cấp bất kỳ ý nghĩa nào để nói về “ngữ nghĩa” của dữ liệu. Ví dụ, không hề có một định hướng về mặt ngữ nghĩa nào liên quan tới việc lồng các thẻ (tags) với nhau mà hoàn toàn tùy thuộc vào cách mà mỗi ứng dụng thông dịch. Ví dụ, chúng ta có phát biểu:

David Billington is a lecturer of Discrete Mathematics.

Có nhiều cách để biểu diễn phát biểu này trong XML, chẳng hạn

<course name="Discrete Mathematics">

<lecturer>David Billington</lecturer>

</course>

Hoặc

<lecturer name="David Billington">

<teaches>Discrete Mathemtatics</teaches>

</lecturer>

Hoặc:

<teachingOffering>

<lecturer>David Billington</lecturer>

<course>Discrete Mathematics</course>

</teachingOffering>

Hai cách biểu diễn đầu tiên có thứ tự lồng các tags trái ngược nhau song chúng vẫn diễn đạt cùng một thông tin. Vì vậy, không có một tiêu chuẩn nào quy định ý nghĩa đối với việc lồng thẻ.

Mặc dù thường được gọi là “ngôn ngữ” nhưng RDF thực chất là một mô hình dữ liệu (data – model). Nội dung cơ bản của nó chính là bộ ba object-attribute-value hay còn gọi là một statement. Ví dụ như câu ở trên về Billington là một phát biểu. Dĩ nhiên, một mô hình dữ liệu trừu tượng cần một cấu trúc cú pháp để biểu diễn và truyền đạt, do đó RDF có cú pháp hoàn toàn tương tự như XML. Chính vì vậy, nó thừa hưởng mọi ưu thế, lợi ích từ XML. Tuy nhiên, cũng cần biết rằng vẫn tồn tại những cú pháp khác để biểu diễn RDF, do đó cú pháp dựa trên nền XML không phải là thành phần tối cần thiết trong mô hình RDF.

RDF độc lập với miền ứng dụng (domain – independent), tức là không hề có sự giả định trước nào về một miền ứng dụng đặc biệt nào được đưa ra. Nó hoàn toàn tùy thuộc vào người dùng để định nghĩa từ vựng (terminology) trong một lược đồ ngôn ngữ gọi là RDF Schema (RDFS). Gọi là RDF Schema thực sự là không chính xác vì nó gợi lên rằng RDF Schema có mối quan hệ với RDF tương tự như là XML Schema với XML, nhưng thực sự không phải vậy. XML Schema ràng buộc cấu trúc của tài liệu XML trong khi đó RDF Schema định nghĩa từ vựng sử dụng trong các mô hình dữ liệu RDF. Trong RDFS, chúng ta có thể định nghĩa các từ vựng, chỉ ra loại thuộc tính nào được dành cho loại đối tựơng nào và những giá trị nào mà chúng có thể nhận, cũng như mô tả mối quan hệ giữa các objects.Ví dụ:

Lecturer is a subclass of academic staff member.

Câu này có nghĩa là tất cả các “lecturer” đều là “academic staff member”. Điều đáng chú ý ở đây đó là đã có một ý nghĩa mang tính định hướng được gán với “is a subclass of” tức là đã xuất hiện mối quan hệ “có hướng”. Lúc này, nó không còn phụ thuộc vào các ứng dụng khi biên dịch khái niệm này. Ý nghĩa mang tính định hướng này phải được “quan tâm” bởi các phần mềm xử lý RDF. Nhờ khả năng “điều chỉnh” tính ngữ nghĩa của bất kỳ thành phần, RDF/RDFS cho phép chúng ta mô hình hóa một miền ứng dụng riêng.

Ví dụ sau minh họa tính quan trọng của RDF Schema:

<academicStaffMember>Grigoris Antonio</academicStaffMember>
<professor>Michael Maher</professor>
<course name="Discrete Mathematics">

<isTaughtBy>David Billington</isTaughtBy>

</course>

Giả sử chúng ta cần tìm tất cả các “academic staff members”, khi đó, biểu thức XPath sẽ là:

//academicStaffMember

Kết quả chỉ là Grigoris Antoniou. Tuy nhiên trong tình huống này, câu trả lời này không thỏa mãn về mặt ngữ nghĩa. Với con người, kết quả này phải bao gồm cả Michael Maher và David Billington bởi vì:

  • Mọi “professor” đều là “academic staff member” (bởi vì “professor is a subclass of academicStaffMember”).
  • Các “Courses” chỉ được giảng dạy bởi các “academic staff member”

Loại thông tin này tạo ra việc sử dụng mô hình ngữ nghĩa cho các miền ứng dụng riêng biệt, và không thể được hiện thực với XML hay RDF, tuy nhiên loại ngữ nghĩa điển hình này được khai báo trong RDF Schema. Theo đó, RDFS tạo ra thông tin mang tính ngữ nghĩa mà máy tính có thể truy cập được theo như viễn cảnh mà Semantic Web vạch ra.