DEMANDA

uncle(X,Y) :- uncle(X,Z), uncle(Z,Y).

This restriction is deliberate as it allows for many automatic optimisations that are much more difficult or even not possible in more expressive languages. However, since many applications need to perform more powerful query tasks while at the same time making use of the advantages of database management systems (like efficient storage and access, concurrency, etc.), database management systems have been combined with more expressive languages (usually languages providing the full expressiveness of first order logic, or at least the expressiveness of the Horn-fragment of first order logic). Such systems are often referred to as

knowledge base systems [100]. According to [100], “applications require a knowledge-base system if they

have a recursive or nested structure that needs to be queried” (p.983).

Since XML documents and semistructured databases often comprise such nested structures, a query language for such data consequently needs to be more expressive than traditional database query languages like SQL. Consider for example an XML document containing a large text (e.g. a book or this thesis) structured in chapters and sections (for an example, cf. Section 2.4.3). A typical query could be to retrieve all sections (at arbitrary level of nesting) where the title contains the substring “XML”. Since this query needs to consider sections at an depth unknown by the query author, such queries cannot be expressed in languages that do not support recursion. In general, restructuring of graph structured data also requires languages with a higher expressive power than is available in traditional query languages ([4], p.54).

Also, embedding a Web query language into a host language is often not feasible: queries might be exchanged between different Web sites and processed in a distributed manner (e.g. either on the client, or on the server, or on both); relying on a host language would require that all participating Web sites are able to evaluate the query language as well as the host language. Consequently, a Web query language needs to be self-contained (cf. characteristics 3 in Section 3.2 below).

When querying on the Semantic Web (cf. Section 1.3.8), a higher expressiveness is even more important. Reasoners like FaCT [58] or RACER [55] need the expressive power of the description logicSHIQ[59], but the Semantic Web is still in development and more powerful reasoners are conceivable. To support arbitrary Semantic Web reasoners, it is thus desirable to provide query languages that have the same power as general purpose programming languages.

3.2

Desirable Characteristics of Web Query Languages

From Section 3.1, it is already possible to see that Web query languages need to be different from traditional database query languages in terms of expressive power. This section introduces further characteristics that have been deemed desirable for Web query languages. In the article Database Desiderata for an XML

Query Language [73], David Maier summarises 13 such characteristics for XML query languages (David

Maier uses the term XQuery to refer to any XML query language; at the time of publication, the language now called XQuery did not exist). The following is a quote from Section 2 of this article. References have been adapted to point to the correct items and emphasis has been added to improve readability.

1. XML Output

An XQuery should yield XML output. Such a closure property has many benefits. De- rived databases (views) can be defined via a single XQuery. Query composition and decomposition is aided. It is transparent to applications whether they are looking at base data or a query result.

2. Server-side Processing

XQuery should be suitable for server-side processing. Thus, an XQuery should be self- contained, and not dependent on resources in its creation context for evaluation. While an XQuery might incorporate variables from a local context, there should be a “bound” form of the XQuery that can be remotely executed without needing to communicate with its point of origin. An example of local content that should be “bound away” is the local alias for a namespace. (See Requirement 11.)

CHAPTER 3. WEB QUERY LANGUAGES

Selection, extraction, reduction, restructuring and combination should all be possible in a single XQuery. This requirement is a consequence of Requirement 2, really. It should not be necessary to resort to another language or multiple XQueries to perform these operations. One reason is that an XQuery server might not understand the other language, necessitating moving fragments of the desired result back to the sender for final processing. Some of these operations greatly reduce data volumes, so are highly desirable to perform on the server side to reduce network requirements. Further, efficient query optimization and evaluation depends on having as much data access and manipulation described in advance as possible, to plan the best data retrieval, movement and processing strategies.

What I mean my these different operations, briefly:

• Selection: Choosing a document or document element based on content, structure

or attributes.

• Extraction: Pulling out particular elements of a document.

• Reduction: Removing selected sub-elements of an element.

• Restructuring: Constructing a new set of element instances to hold queried data.

• Combination: Merging two or more elements into one.

[. . . ]

4. No Schema Required

XQuery should be usable on XML data when there is no schema (DTD) known in ad- vance. XML data is structurally self-describing, and it should be possible to an XQuery to rely on such “just-in-time” schema information in its evaluation. This capability means XQueries can be used against an XML source with limited knowledge of its documents’ precise structures.

5. Exploit Available Schema

Conversely, when DTDs are available for a data source, it should be possible to judge whether an XQuery is correctly formed relative to the DTDs, and to calculate a DTD for the output. This capability can detect errors at compile time rather than run time, and allows a simpler interface for applications to manipulate a query result.

6. Preserve Order and Association

XQueries should preserve order and association of elements in XML data. The order of elements in an XML document can contain important information – a query shouldn’t lose that information. Similarly, the grouping of sub-elements within elements is usually significant. For example, if an XQuery extracts<title> and<author>sub-elements from<book> elements in a bibliographic data source, it should preserve the<title>-

<author>associations. 7. Programmatic Manipulation

XQueries should be amenable to creation and manipulation by programs. Most queries will not be written directly by users or programmers. Rather, they will be constructed through user-interfaces or tools in application development environments.

8. XML Representation

An XQuery should be representable in XML. While there may be more than one syntax for XQuery, one should be as XML data. (Note that XSL is written in XML.) This property means that there do not need to be special mechanisms to store and transport XQueries, beyond what is required for XML itself. It also helps satisfy Requirement 7. 9. Mutually Embedding with XML

XQueries should be mutually embedding with XML. That is, an XQuery should be able to contain arbitrary XML data, and an XML document should be able to hold arbitrary XQueries. The latter capability allows XML document to contain both stored and virtual data. The former capability allows an XQuery to hold arbitrary constants, and allows for