Đề tài Đọc báo điện tử và tìm kiến thông tin trên Internet

ạng EDI (Electronic Data Interchange). Lập trình phân tán : XML là một công cụ lý tưởng để xây dựng các ứng dụng từ nhiều platform khác nhau, cho phép tích hợp giữa các server của Windows, Unix, Linux, Sun... với các hệ điều hành khác nhau trên toàn thế giới. Cấu trúc Web site : Bản thân XML là một ngôn ngữ mang tính cấu trúc chặt chẽ và phân tán. Vì vậy, các nhà phát triển Web site có thể dễ dàng sử dụng XML trong việc tăng tính phân tầng và cấu trúc duyệt (navigations) đối với những trang Web của họ. Hơn nữa, sử dụng XML sẽ giúp cho việc lưu trữ thông tin người sử dụng, trạng thái Web site, điều khiển luồng dữ liệu trong trang Web trở nên dễ dàng hơn bao giờ hết. XML có thể giúp chúng ta trong việc tương tác với cơ sở dữ liệu, ví dụ như việc nhận dữ liệu từ một câu truy vấn SQL hoặc cập nhật dữ liệu từ một bản ghi XML. Bằng việc mô tả dữ liệu theo định dạng XML, chúng ta không cần phải nhất thiết có một chút khái niệm nào về cấu trúc thật sự của cơ sở dữ liệu khi lưu. Với nền tảng XML chúng ta có thể dễ dàng bổ sung tính ngữ nghĩa cho các thông tin lấy được từ các trang Web. Hệ thống của tôi còn nhắm tới XML như một ngôn ngữ hữu dụng trong việc chuyển đổi sang bất cứ dạng cơ sở dữ liệu (hay cơ sở dữ liệu tri thức) nào khác. Việc dễ dàng chuyển đổi sang các cơ sở dữ liệu khác nhau một cách dễ dàng sẽ giúp đỡ người sử dụng, các doanh nghiệp tiết kiệm được rất nhiều thời gian, công sức tiền bạc và thích ứng được với môi trường Thương mại điện tử một cách dễ dàng. Chương III NGHIÊN CỨUGIẢI PHÁP Giải pháp sử dụng script để tạo sinh URL tổng quát Giải pháp sử dụng DLL để tạo sinh URL tổng quát Bóc tách và gán ngữ nghĩa cho thông tin Khả năng tương tác visual giữa người và máy Hiện thực hóa giải pháp Khả năng ứng dụng và phát triển Như đã nói ở chương trước, để có được tri thức như mong muốn, chúng ta cần thực hiện qua bốn bước thu thập, bóc tách, tổng quát hóa và phân tích dữ liệu. Các bước này liên quan chặt chẽ đến nhau và có thể dễ dàng nhận thấy rằng, việc thực hiện không tốt một bước bất kỳ trong bốn bước kể trên đều ảnh hưởng lớn tới tri thức đầu ra. Với những nghiên cứu sẽ trình bày dưới đây, tôi xin được đặc biệt chú trọng tới hai bước đầu tiên, thu thập và bóc tách thông tin mà trọng tâm là bóc tách thông tin. III.1.THU THẬP THÔNG TIN Việc thu thập thông tin trong hệ thống phải dựa vào những nguồn thông tin mà người sử dụng đã cung cấp cho hệ thống ấy. Sở dĩ tại sao ở đây tôi không đặt trọng tâm vào việc thu thập thông tin là bởi vì hiện tại, các search engine và các nguồn tin từ Web cung cấp thông tin đã quá nhiều, ngày càng phát triển và cung cấp cho người sử dụng nhiều thông tin hơn nhưng lại trong khoảng thời gian ít hơn trước rất nhiều. Cần phải khẳng định rằng hiện tại chúng ta không hề thiếu dữ liệu, do vậy, trong tác vụ thu thập dữ liệu, tôi không thực hiện công việc đi tìm nguồn tin cho người sử dụng (vì công việc tìm nguồn tin giờ đây đã trở nên quá dễ dàng với các search engine) mà là đi tìm cho người sử dụng một cơ chế tự động thu thập dữ liệu từ các nguồn tin để chuẩn bị cho tác vụ thứ hai, tác vụ bóc tách thông tin. III.1.1.Các loại URL Chúng ta cũng cần phải phân biệt rõ các nguồn thông tin. Ở đây, nguồn thông tin của người sử dụng được định danh dưới các dạng URL như sau : URL tĩnh. Ví dụ khi muốn xem tin Thể thao của tờ báo Z có địa chỉ là www.zzz.info, chúng ta chỉ cần truy nhập tới địa chỉ www.zzz.info/The-Thao/ trong mọi trường hợp thì có thể đọc được tin Thể thao của báo Z. URL tĩnh được redirect đến một URL khác động tùy thuộc nhiều yếu tố (ngày, tháng, số lần người sử dụng truy cập...). Quay lại ví dụ với tờ báo Z, giả sử muốn xem Tin Thể thao, bây giờ chúng ta lại phải vào www.zzz.info và sau đó ấn vào chuyên mục Thể thao để truy cập đến phần tin Thể thao với địa chỉ www.zzz.info/24-10/The-Thao/ (với 24-10 là ngày hiện tại). Đây là ví dụ đơn giản nhất về việc có tham số trong địa chỉ URL và nếu chúng ta nắm được quy luật đối với tham số này (trong ví dụ trên thì tham số chính là ngày hiện tại - tháng hiện tại), chúng ta cũng có thể truy cập trực tiếp tới trang Web cần thiết. Từ khóa để sinh ra URL (động). Các ví dụ đơn giản nhất trong trường hợp này là các search engine. Chúng ta đã biết rằng để tìm kiếm thông tin, chúng ta cần phải cung cấp cho các search engine này từ khóa. Các từ khóa ấy được biến đổi và cuối cùng được gửi cho server dưới dạng nằm trong URL. Ngoài ra, cũng còn cần phải xét tới chuyện xử lý sang việc người sử dụng cần lấy từ nguồn tin không phải từ một trang mà là từ nhiều trang Web (ví dụ như mặc dù search engine có thể trả lại cho chúng ta đến hàng triệu kết quả chỉ trong một trang Web, tuy vậy trong thực tế người sử dụng thông thường không muốn xem hết hàng triệu kết quả này cũng như search engine không bao giờ lại trình bày hàng triệu kết quả thu được trong một trang Web duy nhất). Như vậy, thông tin về số trang trong trường hợp này ở trên URL cũng cần phải nghiên cứu. Chúng ta cũng cần phải phân biệt được trường hợp 3 và 2 là giống nhau về mặt bản chất URL đều được mã hóa, nhưng trong trường hợp thứ 3 thông tin mã hóa được nhập từ người sử dụng, còn trong trường hợp thứ 2 thì do máy tính tự sinh ra. III.1.2. Giải pháp xử lý Đối với từng loại URL này, tôi đã có những nghiên cứu và đưa ra các giải pháp khả thi để có thể xử lý hết tất cả các trường hợp tạo sinh URL và sau đó quy về một URL tĩnh request đến server chứa nguồn thông tin. Trừ URL tĩnh là dạng URL cơ bản nhất còn các dạng URL còn lại đều có thể được tạo sinh bởi một trong hai cách dưới đây : Tạo/sinh URL bằng cách viết script. Đây là nhóm các URL được mã hóa đơn giản, có thể nhìn thấy ngay quy luật. Tạo/sinh URL bằng cách viết DLL. Trong trường hợp các URL sử dụng các phương pháp mã hóa phức tạp hơn, để tiện cho người sử dụng, cách tốt nhất là người sử dụng viết một DLL hoặc sử dụng DLL có sẵn như một plug-ins để cung cấp cho hệ thống của tôi khả năng tạo/sinh URL dựa trên việc gọi các hàm trong DLL (plug-ins) đó. 1.2.1. Tạo sinh URL bằng cách viết script Trước hết, cần khảo sát qua những yêu cầu để có thể xây dựng nên script. Để khảo sát, chúng ta sẽ lấy các URL của các search engine trong và ngoài nước đối với chuỗi “Trí Tuệ Việt Nam” và một số tờ báo, mỗi trang lấy 3 URL và tổng quát hóa từ các ví dụ này để rút ra quy luật. (Tại báo cáo này, tôi chỉ trình bầy một số ít trong các ví dụ thực tế mà tôi đã khảo sát và nghiên cứu). Google : Phần cố định Keyword sau khi mã hoá Phần cố định Phần thay đổi Phần cố định %2B%22Tr%C3%AD+Tu%E1%BB%87+Vi%E1%BB%87t+Nam%22& num=50&hl=vi&lr=&ie=UTF-8&oe=UTF-8&safe=off&start= 50 100 150 sa=N Alltheweb : Phần cố định Keyword sau khi mã hoá Phần cố định Phần thay đổi Phần cố định %22Tr%C3%AD+Tu%E1%BB%87+Vi%E1%BB%87t+Nam%22& &c=web&cs=utf-8&o= 10 20 30 &l=any PanVN : "Tr%C3%ADTu%E1%BB%87Vi%E1%BB%87tNam"&fcid=2&any=&ww=&occ=&d=&cmdSearch=Search&advs=&pn=2&dns=&img=0 "Tr%C3%ADTu%E1%BB%87Vi%E1%BB%87tNam"&fcid=2&any=&ww=&occ=&d=&cmdSearch=Search&advs=&pn=3&dns=&img=0 "Tr%C3%ADTu%E1%BB%87Vi%E1%BB%87tNam"&fcid=2&any=&ww=&occ=&d=&cmdSearch=Search&advs=&pn=4&dns=&img=0 Phần cố định Keyword sau khi mã hoá Phần cố định Phần thay đổi Phần cố định "Tr%C3%ADTu%E1%BB%87Vi%E1%BB%87tNam" &fcid=2&any=&ww=&occ=&d=&cmdSearch=Search&advs=&pn= 2 3 4 &dns=&img=0 VinaSeek : Phần cố định Keyword sau khi mã hoá Phần cố định Phần thay đổi %22Tr%DD+Tu%D6+Vi%D6t+Nam%22 &start= 21 41 61 Đài Tiếng Nói Việt Nam Chuyên mục Kinh tế : Chuyên mục Xã Hội : Chuyên mục Thể Thao : Phần cố định Phần thay đổi Phần cố định 2004_10_24 /vietnamese/kinhte.htm 2004_10_24 /vietnamese/xahoi.htm 2004_10_24 /vietnamese/thethao.htm Như vậy, để xử lý được toàn bộ các URL này, script của chúng ta phải đáp ứng được nhưng yêu cầu sau : Mã hóa được keyword theo dạng chuẩn của Windows Có các hàm để thay thế chuỗi (ví dụ nếu chú ý thì trong keyword sau khi đã qua xử lý của Google, dấu “ “ đã được thay bằng dấu “+”) Có một số các hàm xử lý tạo ra ngày, tháng, năm hiện tại và các hàm đơn giản khác (hàm không cần đối số, trả về một giá trị) Script phải xử lý được ít nhất là một biến. Cũng cần phải có cơ chế cho biết biến đó được chạy từ đâu đến đâu, bước chạy là bao nhiêu (ví dụ đối với search engine, cần biết là trang thứ bao nhiêu, bắt đầu từ kết quả thứ bao nhiêu...) Do vậy, tôi đã xây dựng một ngôn ngữ script dựa vào những yêu cầu trên. Ngôn ngữ này là đơn giản, phù hợp với yêu cầu và dễ dàng mở rộng khi cần thiết. Dưới đây là các quy tắc của ngôn ngữ : Các dòng được xử lý tuần tự. Sau khi thực hiện một dòng, kết quả trả về là một chuỗi (trừ dòng đầu tiên) Kết quả thực hiện toàn bộ script là một chuỗi được ghép lại bởi các chuỗi kết quả của từng dòng theo thứ tự (bắt đầu từ dòng thứ 2) Dòng đầu tiên bao gồm chuỗi các số được cách nhau bởi dấu “ “, ít nhất là 1 số và nhiều nhất là 4 số có ý nghĩa sau : Số đầu tiên chỉ xem URL có phần thay đổi cần sử dụng biến hay không ? Nếu bằng 1 là Có Nếu bằng 0 là Không có Ba tham số tiếp theo có các ý nghĩa lần lượt như sau : Khởi đầu Bước tăng Số lần lặp (bằng 0 là vô hạn) Hàm được bắt đầu bằng dấu “$” và phải viết tên hàm bằng chữ hoa Có hai hàm mã hoá keyword(tham số mặc định là keyword, không cần truyền biến nữa) là : $UTF8 : mã hoá dạng UTF8 $TCVN : mã hoá dạng TCVN Vị trí của phần thay đổi cần biến sẽ được thể hiện bằng dòng chỉ chứa dấu “#” Trong toàn bộ script biến “#” chỉ được sử dụng một lần Các dòng không có dấu “#” và “$” đứng đầu không cần phải xử lý gì mà coi luôn giá trị đó là giá trị đầu ra của dòng Các hàm có thể sử dụng được trong script : $UTF8 : mã hóa keyword sang dạng UTF8 $TCVN : mã hóa keyword sang dạng TCVN $REPLACE ts1 ts2 : thay chuỗi ts1 bằng chuỗi ts2 trong keyword đã mã hóa $YEAR : năm hiện tại $MONTH : tháng hiện tại $DATE : ngày hiện tại Dưới đây tôi sẽ áp dụng quy tắc này để biểu diễn lại các ví dụ trên ra dạng script : Google : Phần cố định Keyword mã hoá Phần cố định Phần thay đổi Phần cố định %2B%22Tr%C3%AD+Tu%E1%BB%87+Vi%E1%BB%87t+Nam%22& num=50&hl=vi&lr=&ie=UTF-8&oe=UTF-8&safe=off&start= 50 100 150 sa=N 1 50 50 3 $UTF8 REPLACE %20 + num=50&hl=vi&lr=&ie=UTF-8&oe=UTF-8&safe=off&start= # sa=N Alltheweb : Phần cố định Keyword mã hoá Phần cố định Phần thay đổi Phần cố định %22Tr%C3%AD+Tu%E1%BB%87+Vi%E1%BB%87t+Nam%22& &c=web&cs=utf-8&o= 10 20 30 &l=any 1 10 10 3 $UTF8 REPLACE %20 + &c=web&cs=utf-8&o= # &l=any PanVN : Phần cố định Keyword mã hoá Phần cố định Phần thay đổi Phần cố định "Tr%C3%ADTu%E1%BB%87Vi%E1%BB%87tNam" &fcid=2&any=&ww=&occ=&d=&cmdSearch=Search&advs=&pn= 2 3 4 &dns=&img=0 1 2 1 3 $UTF8 $REPLACE %22 “ &fcid=2&any=&ww=&occ=&d=&cmdSearch=Search&advs=&pn= # &dns=&img=0 VinaSeek : Phần cố định Keyword mã hoá Phần cố định Phần thay đổi %22Tr%DD+Tu%D6+Vi%D6t+Nam%22 &start= 21 41 61 1 21 20 3 $TCVN $REPLACE %20 + &start= # Đài Tiếng nói Việt Nam : Phần cố định Phần thay đổi Phần cố định 2004_10_24 /vietnamese/kinhte.htm 2004_10_24 /vietnamese/xahoi.htm 2004_10_24 /vietnamese/thethao.htm 0 $YEAR - $MONTH - $DATE /vietnamese/kinhte.htm (có thể thay bằng các chuyên mục khác) Trong ví dụ này, chúng ta chú ý rằng, do không cần lặp lại nên dòng đầu tiên chỉ có 1 tham số là 0, mang ý nghĩa là không có biến. Các dòng nếu không bắt đầu bằng dấu “$” hoặc “#” thì đều được coi là chuỗi hằng và không cần phải biến đổi thêm. Script được tạo ra sẽ được hệ thống xử lý theo sơ đồ sau : Cũng cần phải nhắc lại rằng ngôn ngữ script dùng để tạo/sinh URL tổng quát này còn hết sức đơn giản(cũng do việc tạo/sinh URL không đòi hỏi quá phức tạp). Tuỳ theo độ phức tạp của URL về sau, tôi có thể dễ dàng tạo ra các hàm bổ sung. Tuy vậy, nếu tạo ra quá nhiều hàm bổ sung sẽ dẫn tới việc khó sử dụng và khó hiểu đối với người sử dụng. Do vậy, tôi đưa ra giải pháp dùng DLL như một plug-ins để tạo/sinh URL tổng quát. III.1.2.2.Tạo sinh URL bằng việc sử dụng DLL Như ở trên đã trình bày, việc sử dụng phương pháp dùng script để tạo/sinh URL tuy đơn giản nhưng đã bao trùm được khá nhiều trường hợp. Tuy nhiên tôi cũng lường trước được sự phức tạp đối với việc sử dụng script khi các URL này được mã hóa một cách phức tạp hơn hoặc không có quy luật nhất định có thể nhìn thấy ngay. Ví dụ như một tờ báo có tham số sử dụng trên URL là số báo (ví dụ số 130 năm 2004, số 131 năm 2004) nhưng các số báo này thay đổi không theo quy luật nào (theo ngày...). Để biết được ngày hôm nay báo ra số bao nhiêu thì chỉ có một cách là phải phân tích trang chủ của tờ báo đó để lấy được số báo. Quá trình phức tạp kể trên nên được xử lý một cách “trong suốt” đối với người sử dụng bằng cách sử dụng các DLL thay thế. Các DLL này sẽ được tôi và bất cứ ai yêu thích công việc lập trình viết ra và phải có ít nhất hai hàm theo đúng tên và tham số đầu ra cũng như đầu vào được liệt kê dưới đây : LPSTR GetFirstURL(LPSTR lpURL); Chức năng : Lấy URL khởi đầu Đầu vào : 1 chuỗi ký tự (ví dụ như keyword cho search engine) Đầu ra : URL hoặc danh sách URL đầu tiên LPSTR GetNextURL(LPSTR lpURL); Chức năng : Lấy URL tiếp theo Đầu vào : 1 chuỗi ký tự(thường là danh sách URL đầu ra của lần gọi GetFirstURL hoặc GetNextURL trước đó) Đầu ra : URL hoặc danh sách URL tiếp theo. Nếu kết quả trả lại là rỗng thì có nghĩa là không còn URL nào nữa. Các hàm chuẩn này sẽ được gọi theo sơ đồ như sau : III.2.BÓC TÁCH THÔNG TIN Như đã nói ở trên, để bóc tách thông tin thu được từ tác vụ thứ nhất, chúng ta sẽ xây dựng một “wrapper”. Wrapper có thể được hiểu là những hàm để tách thông tin từ các tài nguyên Web. Các hàm này viết dựa trên các luật (quy luật) đã được đúc rút ra sau khi khảo sát các trang Web chứa thông tin cần lấy. Như vậy, đối với tác vụ này, tôi sẽ phải cung cấp cho người sử dụng một công cụ tạo ra các luật (quy luật) để bóc tách thông tin. Trước khi tiếp tục, tôi cũng xin nhắc lại một chút về mục đích của hệ thống. Hệ thống được xây dựng tập trung vào hai tác vụ đầu của bốn tác vụ webmining, cung cấp cho người sử dụng khả năng thu thập và bóc tách thông tin. Tuy vậy, những thông tin này là những thông tin gì ? Người sử dụng muốn gì và hệ thống của tôi đáp ứng được đến đâu ? III.2.1. Quy luật dùng để bóc tách thông tin Những thông tin được tách ra sau khi sử dụng hệ thống là những thông tin có cấu trúc về mặt ngữ nghĩa. Để bóc tách được những thông tin này, tôi dựa trên một quy luật đơn giản nhưng vô cùng hiệu quả sau : Trong hầu hết các trang Web cung cấp thông tin, các thông tin có ý nghĩa giống nhau sẽ thường được trình bày giống nhau. Ở đây, tôi xin được giả định rằng chiều ngược lại của quy luật này cũng đúng, có nghĩa là, các thông tin được trình bày giống nhau sẽ thường có ngữ nghĩa giống nhau. Sự giải định này rõ ràng là không đúng hẳn trong một số trường hợp. Tuy vậy, cho đến nay với sự nghiên cứu của tôi, cả hai giả định theo chiều thuận và nghịch là hầu như hoàn toàn đúng (vì có một chiều hướng rõ ràng rất cần phải nhấn mạnh là nếu như các thông tin có ý nghĩa giống nhau chưa được trình bày giống nhau, các website thông tin sẽ cố gắng định dạng các thông tin này lại cho giống nhau để người sử dụng khi duyệt Web của họ dễ dàng phân biệt thông tin). Chúng ta có thể xét các ví dụ sau đây : III.2.1.1.Ví dụ 1 : Diễn đàn www.diendantinhoc.org Nhìn ví dụ này, chúng ta cũng có thể thấy rõ rằng tên của các box được định dạng theo một kiểu (chữ đậm, màu xanh), tên người viết (chữ nhỏ, màu xanh), ngày viết (chữ nhỏ, màu đỏ)… Trang Web này sẽ được cấu trúc về mặt ngữ nghĩa như sau : Tên khu vực (Tin tức-Kinh nghiệm-Hỏi đáp/Tin học chuyên ngành/…) Tên box (Phần cứng/Phần mềm/…) Giới thiệu box Tên Điều hành viên Số bài trong box (3105/3967/…) Số bài mới (2/5/…) Bài viết mới nhất Tên người viết bài mới nhất Ngày viết của bài mới nhất III.2.1.2. Ví dụ 2 : Báo điện tử VnExpress( Trong ví dụ này, chúng ta có thể thấy tên của chuyên mục đã được định dạng màu đỏ và chữ to đậm, tên của bài viết được định dạng chữ đậm và phần mô tả được định dạng theo kiểu chữ thông thường. Cũng có thể chú ý một chút tới phần tỷ giá, các thông tin về tên đơn vị tiền tệ và trị giá đơn vị tiền tệ cũng được định dạng để sao cho dễ dàng phân biệt được với các thông tin khác. Trang Web này sẽ được cấu trúc về mặt ngữ nghĩa như sau : Tên mục chính Tên bài mới cập nhật Ảnh bài mới cập nhật Mô tả bài mời cập nhật III.2.1.3.Ví dụ 3 : Search engine www.panvn.com (với từ khoá “Trí Tuệ Việt Nam”) Lại một lần nữa chúng ta thấy rất rõ tiêu đề của kết quả được search engine định dạng chữ đậm, màu xanh và cỡ chữ to để phân biệt với phần mô tả tiêu đề cỡ chữ nhỏ và màu đen. Qua 3 ví dụ này và các ví dụ mà người sử dụng có thể dễ dàng nhận ra khi duyệt các trang Web thông tin, nhất là các trang Web thông tin có cấu trúc, các thông tin có ngữ nghĩa giống nhau thường được định dạng giống nhau và ngược lại. Trang Web này sẽ được cấu trúc về mặt ngữ nghĩa như sau : Số thứ tự Tiêu đề trang Web được tìm thấy Trích đoạn có từ khóa cần tìm kiếm trong trang Web được tìm thấy URL ... III.2.2.Phương án kỹ thuật Quy luật trên chính là mấu chốt để có thể chuyển đổi thông tin từ dạng ngôn ngữ HTML sang ngôn ngữ XML, từ việc thông tin chỉ được định dạng mà không biết ý nghĩa tới việc thông tin đã được gắn ngữ nghĩa. Từ các thông tin có ngữ nghĩa này, chúng ta có thể trả lời cho các câu hỏi như “Hôm nay giá cổ phiếu công ty nào là tăng cao nhất ?“ hay “Chuyên mục Thể Thao của báo VnExpress có bài nào nói về Đội tuyển Bóng đá Việt Nam hay không ?”. Để có thể hiện thực hóa được quy luật này, cần có một cơ chế để phân biệt các thông tin được trình bày giống nhau và sau đó là cơ chế phân tích các thông tin này nhanh và tiện dụng do người sử dụng. III.2.2.1. Làm thế nào để biết các thông tin đươc đinh dang giống nhau ? Để phân biệt được các thông tin được định dạng giống nhau, chúng ta sẽ phân tích qua một ví dụ cụ thể dưới đây. Đây là một phần của trang chuyên mục Thể Thao, báo điện tử VnExpress, Chủ nhật, ngày 27-10-2004. Chúng ta chú ý đến các thông tin giống nhau dễ nhận thấy nhất là tiêu đề bài viết. Các tiêu đề này ứng với các nút A trên cây HTML đã được phân tích. Chúng ta có thể có một vài nhận xét về các nút này như sau : Các nút A là nút lá trên cây HTML (không là cha của bất cứ nút nào trên cây) Nếu đi từ nút gốc (HTML) tới nút con này, vết ghi lại (đi qua một nút thì ghi lại tên) là giống nhau (HTML->TABLE->TBODY->TR->TD->TABLE->TBODY->TR->TD->A) Khi xét các trang chuyên mục Thể thao đối với các ngày khác, thậm chí là khi xét đối với bất kỳ một trang chuyên mục nào khác của báo điện tử VnExpress, vết ghi lại đối với phần tiêu đề là không thay đổi. Dường như với quy luật nhận xét trong phần III.2.2.1 cùng với những nhận xét này, chúng ta có thể thấy rằng việc bóc tách thông tin đã nằm trong tầm tay (phân tích cây HTML, sau đó duyệt cây HTML để lấy ra những thông tin theo vết ghi lại có sẵn) . Tuy vậy, sau khi nghiên cứu kỹ, tôi nhận thấy việc bóc tách thông tin vẫn còn rất nhiều những khó khăn. Chúng ta sẽ tiếp tục nghiên cứu tiếp ví dụ này cùng với các ví dụ và kỹ thuật khác để lần lượt giải quyết các khó khăn này. III.2.2.2.Phân tích trang HTML Như đã phân tích và nhận xét trong phần trên, việc phân tích cây HTML là rất quan trọng. Dựa trên các cơ chế lập trình tương đương với cơ chế phân tích cây HTML của trình duyệt Internet Explorer, tôi đã có thể thực hiện được công việc phân tích cây này. Quá trình thực hiện phân tích cây HTML từ một trang Web không phải là đơn giản, do việc tạo ra các trang Web từ ngôn ngữ HTML có thể không cần phải well-formed (bất cứ khi nào có một thẻ mở cũng phải có thẻ đóng tương ứng) như ngôn ngữ XML. III.2.2.3.Các thuộc tính thông tin quan trọng Sau khi đọc những kết luận thu được từ phần III.2.2.1, chắc hẳn chúng ta sẽ phải đặt ra câu hỏi, phải chăng mọi chuyện đều đơn giản quá như thế ? Phải chăng chỉ cần phân tích trang Web ra dạng cây và ghi lại các vết duyệt từ nút gốc tới nút lá cần bóc tách là xong ? Chúng ta có thể giả sử rằng vẫn trong trang chuyên mục Thể thao của báo VnExpress, các tiêu đề của phần Tin đã đưa cũng có vết giống hệt như phần Tiêu đề tin thì sao ? Trong lúc đó, xét về mặt ngữ nghĩa, phần Tin đã đưa rõ ràng có ý nghĩa khác hẳn so với phần Tiêu đề tin mới và chúng ta không thể trả về kết quả không rõ ràng như vậy cho người sử dụng (chung cả hai phần Tiêu đề tin mới và Tin đã đưa). Do vậy, chúng ta sẽ phải tiếp tục nghiên cứu kỹ hơn về từng thẻ ngôn ngữ HTML riêng để có thể phân biệt được các thông tin một cách chi tiết hơn(vì đơn giản theo đúng quy luật mà chúng ta đã nghiên cứu, những người soạn báo điện tử cũng sẽ cố gắng không bao giờ trình bày phần Tiêu đề tin mới và phần Tin đã đưa giống hệt nhau để tránh nhầm lẫn). Như chúng ta đã biết, mỗi thẻ của ngôn ngữ HTML đều có những thuộc tính khác nhau. Chúng ta sẽ phải quan tâm nhất đến các thuộc tính có ảnh hưởng tới việc trình bày ra ngoài màn hình (hoặc các thiết bị khác). Tôi đã tổng kết ra đây một số các thuộc tính không thuộc CSS có thể ảnh hưởng tới việc trình bày một thẻ trong khi duyệt trang Web (chứ không phải tất cả các thuộc tính đều ảnh hưởng tới việc trình bày). Các thuộc tính thuộc CSS được trình duyệt thực hiện qua classname nên không cần xét tới. Tên thuộc tính Ý nghĩa của thuộc tính Xuất hiện trong các thẻ align Kiểu căn lề (Trái, phải, giữa) APPLET,EMBED, FIELDSET,IMG... allowtransparency Đặt chế độ trong suốt FRAME,IFRAME... alinkColor Mầu của các link active Document background Ảnh nền của object BODY,TABLE,TD,TH bgcolor Màu nền của object BODY,MARQUEE,TABLE,COL,COLGROUP... bordercolor Màu viền của object FRAME,FRAMESET... bordercolordark Màu viền đậm của object TABLE,TD,TH,TR bordercolorlight Màu viền nhạt của object TABLE,TD,TH,TR cellindex Số hiệu cell TD,TH color Màu của Text A,ADDRESS,B,BIG,TABLE,XMP... classname Class của object A,ADDRESS,B,BIG,TABLE,XMP... clear Vị trí Object... BR clip Phần Object ẩn A,ADDRESS,B,BIG,TABLE,XMP... dir Thứ tự của Object A,ADDRESS,B,BIG,TABLE,XMP... face Font Face BASEFONT,FONT fgColor Màu chữ của Object Document frameborder Có vẽ viền Object không ? FRAME,FRAMESET,IFRAME framespacing Khoảng cách giữa FRAME FRAMESET nowrap Wordwrap BODY,DD,DIV,DT,TD,TD,TH size Kích cỡ BASEFONT,FONT,HR,INPUT... vAlign Kiểu canh lề CAPTION,COL,TBODY,TFOOT… … … … Do vậy, bây giờ chúng ta không những phải xét xem vết khi duyệt cây có giống nhau không, mà còn phải xét xem từng thuộc tính ở các nút cùng mức(có khoảng cách tới nút gốc là bằng nhau trên cây) có giống nhau không. Ví dụ như với phần Tiêu đề của báo VnExpress kể trên, kết hợp cả tên nút và thuộc tính của từng nút trong vết, chúng ta sẽ có một mẫu so sánh như sau : III.2.2.4.Tăng tính khả mở của các mẫu so sánh Chúng ta đã có hai kết luận quan trọng trong khi khảo sát trang chuyên mục Báo điện tử VnExpress về các thông tin có ngữ nghĩa giống nhau như sau : Các vết ghi lại khi duyệt từ nút gốc tới nút chứa các thông tin giống nhau về mặt ngữ nghĩa trên cây HTML là không đổi Từng nút có cùng độ sâu khi duyệt thì cũng có các thuộc tính liên quan tới việc trình bày trên trang Web là giống nhau Hai kết luận này là đã đủ để bóc tách thông tin từ rất nhiều các Website có cấu trúc như báo điện tử, diễn đàn, forum… Tuy vậy, cũng có thể thấy rằng kết luận 1 là không hoàn toàn chính xác và bao quát được hết tất cả các trường hợp vì vẫn có những trường hợp các thông tin có cùng ngữ nghĩa do vô tình/cố ý không có các vết ghi lại khi duyệt là không đổi. Để ví dụ cho trường hợp này, chúng ta hãy xét một ví dụ tiêu biểu khác. Dưới đây là trang chuyên mục Thể Thao, báo Lao động điện tử ngày 27-10-2004. Chúng ta có thể dễ dàng thấy rằng, vết ghi lại sau khi duyệt từ nút gốc HTML tới nút chứa tiêu đề của bài báo không còn giống nhau. Với tiêu đề “Hãy tin tưởng đội khách”, chúng ta có vết khi duyệt cây như sau : HTLM->BODY->TABLE->TBODY->TR->TD->TABLE->TBODY->TR->TD->TABLE->TBODY->TR->TD->FONT Với tiêu đề “Chim non đã lớn” và “Vui lạ”, chúng ta có vết khi duyệt cây như sau : HTLM->BODY->TABLE->TBODY->TR->TD->TABLE->TBODY->TR->TD->TABLE->TBODY->TR->TD->A->FONT Để có thể giải quyết vấn đề này, tôi đã đưa ra được một phương thức tổng quát hóa sau khi có các vết khác nhau và áp dụng thành công đối với không chỉ riêng báo Lao động mà còn nhiều các trang Web thông tin khác. Ở đây, chúng ta chỉ cần chú ý rằng kể từ mức thứ nhất là nút gốc HTML tới nút số 14, vết ghi lại khi duyệt là giống nhau, tuy vậy trong nút thứ 15, chúng ta sẽ có hai trường hợp : Nếu gặp nút FONT sẽ đưa ra kết quả và không duyệt tiếp nữa Nếu gặp nút A sẽ tiếp tục duyệt, nếu gặp nút FONT là con của nút A thì đưa ra kết quả Cuối cùng, để kết thúc phần này, chúng ta có thể đưa ra được hai kết luận dựa trên quy luật nhận xét ở phần III.2.2.1 như sau : Các vết ghi lại khi duyệt từ nút gốc tới nút chứa các thông tin giống