Dữ liệu có cấu trúc là gì?

Định nghĩa

Dữ liệu có cấu trúc là thông tin được tổ chức theo một mô hình rõ ràng để phần mềm có thể nhận diện các trường, loại, mối quan hệ và ràng buộc một cách nhất quán. Một bảng với các cột được đặt tên, một đối tượng JSON theo một lược đồ đã được tài liệu hóa, và đánh dấu sản phẩm sử dụng Schema.org đều có cấu trúc vì người tiêu dùng biết mỗi giá trị đại diện cho điều gì. Cấu trúc không đảm bảo độ chính xác, tính đầy đủ hoặc tính hữu ích; nó làm cho các kỳ vọng có thể được máy đọc và cho phép xác thực, truy vấn, ghép nối, và trao đổi với ít sự mơ hồ hơn.

Câu hỏi thực tiễn không chỉ là thuật ngữ này có nghĩa là gì, mà còn là bằng chứng nào hỗ trợ cho nhãn đó, quyết định nào phụ thuộc vào nó, và cách mà một nhà điều hành xử lý sự không chắc chắn. Hướng dẫn này tách biệt hành vi quan sát được khỏi những giả định để các nhà phát triển, đội ngũ an ninh, kỹ sư dữ liệu, và người mua kỹ thuật có thể sử dụng khái niệm một cách chính xác.

Cấu trúc có nghĩa là một mô hình chia sẻ

Dữ liệu trở nên có cấu trúc khi người sản xuất và người tiêu dùng chia sẻ các quy tắc để diễn giải nó.

Một cột có tên là price cần một quy tắc tiền tệ, kiểu số, chính sách null và mối quan hệ với hàng sản phẩm. Một dấu thời gian cần một định dạng và quy ước múi giờ. Một định danh cần một phạm vi đã được xác định. Nếu không có những quy tắc đó, một bảng gọn gàng có thể vẫn còn mơ hồ về mặt ngữ nghĩa. Từ vựng Schema.org cung cấp một từ vựng web chung cho các thực thể và thuộc tính, trong khi các sơ đồ miền có thể định nghĩa các yêu cầu cục bộ nghiêm ngặt hơn.

Cấu trúc có thể được áp dụng trước khi thu thập, như trong một cơ sở dữ liệu quan hệ, hoặc sau khi thu thập, như trong một pipeline trích xuất ánh xạ nội dung trang vào một lược đồ. Cấu trúc trước đó thường cải thiện việc xác thực; cấu trúc sau là phổ biến khi các nguồn khác nhau.

Dữ liệu có cấu trúc, dữ liệu có cấu trúc bán phần và dữ liệu không có cấu trúc

Các danh mục mô tả mức độ rõ ràng và nhất quán của tổ chức, không phải giá trị kinh doanh của thông tin.

Các hàng quan hệ và bản ghi sự kiện cố định được cấu trúc mạnh mẽ. JSON, XML và HTML thường được gọi là bán cấu trúc vì chúng mang các thẻ hoặc khóa nhưng có thể thay đổi giữa các tài liệu. Tường thuật ngôn ngữ tự nhiên, hình ảnh, âm thanh và tài liệu dạng tự do thường được coi là không có cấu trúc cho một quy trình làm việc cụ thể, mặc dù mỗi định dạng tệp vẫn có cấu trúc nội bộ.

Ranh giới phụ thuộc vào người tiêu dùng. Một bài viết HTML được cấu trúc đủ để trình duyệt có thể hiển thị các tiêu đề, tuy nhiên một quy trình định giá có thể thấy các giá trị của nó là không cấu trúc cho đến khi sản phẩm, số lượng, tiền tệ và tính khả dụng được trích xuất vào các trường.

Dữ liệu có cấu trúc trên các trang web

Dữ liệu cấu trúc web mô tả các thực thể trang trong một từ vựng có thể đọc được bởi máy móc cùng với nội dung hiển thị cho con người.

Các nhà xuất bản thường sử dụng JSON-LD, Microdata hoặc RDFa với các thuật ngữ của Schema.org. The Giới thiệu về dữ liệu có cấu trúc của Google giải thích rằng các hệ thống tìm kiếm sử dụng đánh dấu để hiểu nội dung trang và có thể sử dụng các loại được hỗ trợ cho các tính năng tìm kiếm nâng cao. Đủ điều kiện không phải là một đảm bảo hiển thị, và đánh dấu nên mô tả nội dung hiển thị cho người dùng.

Web markup nên sử dụng loại chính xác nhất, các định danh ổn định, thuộc tính chính xác và URL chuẩn. Nó phải được cập nhật khi trang hiển thị thay đổi. Việc thêm thuộc tính chỉ vì một trình xác thực chấp nhận chúng có thể tạo ra mâu thuẫn và làm yếu lòng tin.

Các sơ đồ, Xác thực và Chất lượng Dữ liệu

Một lược đồ định nghĩa các hình dạng được phép, trong khi xác thực kiểm tra xem một thể hiện có tuân theo chúng hay không.

Một lược đồ quan hệ có thể hạn chế các cột và khóa. Cấu trúc JSON Schema xác định một từ vựng để mô tả cấu trúc của thể hiện JSON. Các hợp đồng miền có thể thêm các quy tắc kinh doanh như giá dương, các loại tiền tệ được hỗ trợ, hoặc mã danh mục hợp lệ. Việc xác thực nên chạy khi tiếp nhận và trước khi xuất bản để lỗi được phát hiện gần nguồn gốc của nó.

Việc vượt qua kiểm tra cấu trúc không chứng minh rằng các thông tin là chính xác. Một mức giá có thể là một số hợp lệ và vẫn liên quan đến sản phẩm sai. Kiểm soát chất lượng cũng cần có nguồn gốc, độ tươi, tính độc nhất, tính hoàn chỉnh, tính toàn vẹn tham chiếu và sự đối chiếu với bằng chứng nguồn.

Tại sao Dữ liệu Có cấu trúc lại Quan trọng

Dữ liệu có cấu trúc giảm chi phí của việc truy vấn đáng tin cậy, tự động hóa, trao đổi, và quản lý.

Các nhóm có thể lọc, tổng hợp, kết hợp và giám sát các trường mà không cần phải diễn giải lại văn bản cho từng mục đích. Các API có thể hứa hẹn các hợp đồng phản hồi ổn định. Phân tích có thể tính toán các chỉ số tương đương. Danh mục dữ liệu có thể mô tả quyền sở hữu và độ nhạy cảm. Các đường ống học máy có thể tách các tính năng khỏi nhãn và theo dõi các thay đổi.

I'm sorry, but it seems that you didn't provide the text you want to be translated. Please provide the specific text, and I'll be happy to help! W3C Dữ liệu trên Web Thực tiễn Tốt Nhất nhấn mạnh khả năng tìm kiếm, siêu dữ liệu, cấp phép, nguồn gốc và định dạng có thể đọc được bởi máy cho dữ liệu web. Những thực tiễn này quan trọng hơn cả các tập dữ liệu mở: một bảng nội bộ không có chủ sở hữu, định nghĩa, hoặc quy tắc cập nhật thì khó có thể tin cậy ngay cả khi mỗi hàng đều phù hợp với sơ đồ.

Rút trích có cấu trúc từ web

Trích xuất web biến các trang nguồn thành các bản ghi chỉ sau khi phát hiện, lập bản đồ, chuẩn hóa và xác thực.

Ưu tiên các API của bên thứ nhất và dữ liệu cấu trúc nhúng khi chúng đáp ứng trường hợp sử dụng. Nếu việc thu thập được ủy quyền cần các trang đã hiển thị, xác định các nguồn ổn định như JSON-LD, thuộc tính dữ liệu hoặc nhãn ngữ nghĩa trước các bộ chọn hình ảnh mong manh. Bảo tồn URL nguồn và thời gian thu thập, lập bản đồ các trường một cách rõ ràng và coi các giá trị vắng mặt là null thay vì tạo ra các giá trị mặc định.

Scrapeless Universal Scraping API có thể lấy nội dung công khai để phân tích hạ nguồn, nhưng hợp đồng trích xuất vẫn là trách nhiệm của bạn. Định nghĩa sơ đồ, bằng chứng trường, lỗi xác thực, tần suất cập nhật và thời gian lưu giữ trước khi mở rộng công việc.

So sánh nhanh

Các sự phân biệt sau đây giúp đặt khái niệm vào một quy trình vận hành mà không làm sụp đổ các kiểm soát khác nhau thành một nhãn.

Danh sách kiểm tra đánh giá thực tế

Một triển khai đáng tin cậy bắt đầu bằng việc đặt tên bề mặt được bảo vệ hoặc thu thập một cách chính xác. Ghi lại URL hoặc điểm cuối, hành động người dùng dự kiến, các trường dữ liệu liên quan, các điều khoản quản lý, khách hàng dự kiến và chủ sở hữu có thể phê duyệt quyền truy cập. Sau đó, định nghĩa bằng chứng có thể thay đổi quyết định. Điều này ngăn một nhãn mơ hồ trở thành một cái cớ cho việc thu thập rộng rãi hoặc một chướng ngại vật vĩnh viễn.

Xem xét những gì là dữ liệu cấu trúc bất cứ khi nào một bản phát hành trình duyệt, chính sách bảo mật, nguồn dữ liệu, sơ đồ hoặc mục đích kinh doanh thay đổi. Một mẫu lịch trình nhỏ có tính thông tin hơn một cuộc khảo sát không được kiểm soát lớn: so sánh kết quả dự kiến với kết quả quan sát được, phân loại sự khác biệt và chuyển nó đến chủ sở hữu có thể sửa chữa nguồn hoặc chính sách. Giữ lại các trường và quy tắc không còn ảnh hưởng đến quyết định. Tần suất này biến một định nghĩa một lần thành một kiểm soát hoạt động có thể được kiểm toán, giải thích và cải thiện mà không thu thập nhiều dữ liệu hơn những gì quy trình cần.

• Xác nhận mục đích. Gắn mỗi tín hiệu và trường vào một nhu cầu về bảo mật, khả năng tương thích, xuất bản hoặc chất lượng dữ liệu đã được tài liệu.
• Thay đổi một biến tại một thời điểm. Các so sánh có kiểm soát tạo ra các giải thích tốt hơn so với nhiều thay đổi cấu hình đồng thời.
• Đo lường chi phí người dùng. Theo dõi từ chối sai, bỏ lỡ, nhu cầu hỗ trợ, độ trễ và tác động đến khả năng truy cập bên cạnh kết quả bảo mật.
• Giữ một dấu vết bằng chứng. Giữ một log tối thiểu, URL nguồn, phiên bản sơ đồ và phân loại quyết định mà không thu thập dữ liệu cá nhân không liên quan.
• Cung cấp đánh giá. Người dùng, đối tác và các nhà thu thập đã được phê duyệt cần một lộ trình để sửa chữa một phân loại sai.

Kết luận

Khái niệm Dữ liệu Cấu trúc dễ hiểu nhất khi định nghĩa, bằng chứng, quyết định và giới hạn vẫn tách biệt. Khái niệm này miêu tả một cơ chế kỹ thuật quan sát được hoặc mô hình dữ liệu; nó hiếm khi chứng minh danh tính, ý định, chất lượng hoặc sự cho phép chỉ bằng chính nó. Các triển khai tốt sử dụng các tín hiệu nhỏ nhất cần thiết, xác thực chúng trong ngữ cảnh, giám sát lỗi và giữ một lộ trình đánh giá rõ ràng cho con người.

Đối với công việc dữ liệu web, ưu tiên các API chính thức và xuất khẩu, chỉ thu thập thông tin công khai cần thiết cho mục đích đã nêu và thiết kế một sơ đồ ổn định trước khi mở rộng. Khi việc kết xuất trình duyệt hoặc thu thập quản lý là hợp lý, hãy sử dụng Scrapeless trong phạm vi đã được phê duyệt và giữ cho quy trình có thể tái tạo.

Tài liệu tham khảo

• Tài liệu liên quan đến Scrapeless
• Tổng quan về sản phẩm API thu thập dữ liệu toàn cầu Scrapeless
• Hướng dẫn thu thập dữ liệu HTML trên Web
• Các dự án mã nguồn mở Scrapeless trên GitHub