On the Difference between Navigating Semi-structured Data and Querying It

Currently, there is tremendous interest in semi-structured (SS)data management. This is spurred by data sources, such as the ACeDB [29], that are inherently less rigidly structured than traditional DBMS, by WWW documents where no hard rules or constraints are imposed and “anything goes,” and by integration of information coming from disparate sources exhibiting considerable differences in the way they structure information. Significant strides have been made in the development of data models and query languages [2, 11, 17, 6, 7], and to some extent, the theory of queries on semi-structured data [1, 23, 3, 13, 9]. The OEM model of the Stanford TSIMMIS project [2] (equivalently, its variant, independently developed at U.Penn. [11]) has emerged as the de facto standard model for semi-structured data. OEM is a light-weight object model,which unlike the ODMG model that it extends, does not impose the latter’s rigid type constraints. Both OEM and the Penn model essentially correspond to labeled digraphs. Amain theme emerging from the popular query languages such as Lorel [2], UnQL [11], StruQL [17], WebOQL [6], and the Ulixes/Penelope pair of the ADM model [7], is that navigation is considered an integral and essential part of querying. Indeed, given the lac of rigid schema of semi-structured data, navigation brings many benefits, including the ability to retrieve data regardless of the depth at which it resides in a tree (e.g.,see [4]). This is achieved with programming primitives such as regular path expressions and wildcards. A second, somewhat subtle, aspect of the emerging trend is that query expressions are often dependent on the particular instance they are applied to. This is not surprising, given the lac of rigid structure and the absence of the notion of a predefined schema for semi-structured data. In fact, it has been argued [4] that it is unreasonable to impose a predefined schema.