Queries: INEX 2003 working group report

s Abstracts ( ) are also textual elements with a slightly different semantics, since they contain a condensed description of the content of an article, and no detail information. Bibliographical entries Bibliographic entries are a different class of answers, since they contain only references to publications, but no real “content” like the textual elements. They represent information needs such as “find references to papers about compression” or “give me all bibliographic details of publications cited within papers about compression”. Note that for example queries such as //article[about(.,’neural networks’)]//fm//au which says something like ”give me authors of articles about neural networks” are not considered interesting. From an IR perspective this query is equivalent to the query ”give me articles about neural networks”. The problem of extracting the authors is trivial. Therefore author names is not considered here as a natural target. The above list is based on discussion in the working group and it is not necessary complete. If topic authors find other natural target elements they are encouraged to use them. 2.2 Structural conditions The working group distinguished three natural types of structural conditions. Co-occurrences We want certain concepts to be covered in the same unit. Say, for example we would like to retrieve documents that discuss the use of handheld computers in health care. We would like to minimize the change of getting documents that discuss handheld computers and health care separately. We could try to express this in a query that asks for articles were handheld computers and health care are discussed in the same section. //article[about(.//sec,’handheld computers health care’)] Note that since we are doing IR, we do not enforce term occurrence restrictions. By co-occurrences we are referring to the co-occurrence of concepts but not terms. Data-types Data-types are interesting for retrieval in structured documents. For this particular collection they are of limited use. They should however be considered in retrieval from semantically richer collections which contain not only layout semantics. Examples are markup for chemical processes, financial market developments and geographical locations. Roles We want to restrict our attention to XML elements that represent a certain role; such as article author, author affiliation, etc. For example if we want articles authored by Bruce Croft: //article[about(.//fm//au,’Bruce Croft’)] Similarly if we want articles that cite Bruce Croft: //article[about(.//bb//au,’Bruce Croft’)] We could also restrict our attention to articles where an author is affiliated in California: //article[about(.//fm//au//aff,’California’)] This list of natural constraints must be viewed in the context of the current collection. Different collections have different information needs. For collections that have a larger variety in tag-names it is probably easier to formulate natural structural queries. 2.3 Separation of constraints and targets It was discussed whether the structural constraints and targets needed to be expressed in the same expression. More precisely the question was whether we should go back to the INEX 2002 notation. The main reason behind abandoning the INEX 2002 notation, was that the semantics of that notation was unclear. Consider for example the query //sec[about(.,’solar powered robots’) and about(.//fig,’robot on mars’)] Where we want the retrieved sections to contain figures. Note however, that this is perhaps not a good example for the current LTEX–originated collection, since authors often use tricks to include figures. 3. QUERY LANGUAGE FOR INEX 2004 This section will report on the discussion within the working group about requirements for a query language. We will then outline the syntax and semantics of a query language that is currently being constructed as a future language for INEX. 3.1 Requirements The existing syntax of CO proved adequate. Any changes must maintain compatibility with the existing CO topics. As a query language for CAS titles, the group considered an extension of a subset of XPath. The idea is to take the current syntax extension of XPath, used at INEX 2003, but restrict the usage to an ”IR minimum” as described in [4]. This restriction in functionality supports all the important features used in previous workshops. Some queries are known to contain deprecated features and are excluded from this compatibility requirement. There already exist two data types, numeric and string. This is anticipated to expand in the future to include names, units of measure, and even geographic locations. The language must be extensible to include these at a future date. Tag instancing is to be deprecated. Restricting a search to a first paragraph (p[1]) was considered unnecessary and unlikely to be used. Query 13 already uses this feature, but this query was considered contrived. Furthermore no relevance assessments are available for this query. The use of XPath axis, the plethora of XPath syntax for discussing paths, is to be limited to the descendant axis. In particular, the child axis is to be outlawed. None of the queries used so-far, relied on the usage of the child axis. The child axis can be added at any time if a future collection calls for such information need. Path filtering is to remain. Application of multiple filters is to remain. Use of the (not)-equal operator is to be deprecated for the string data-type. All textual queries are to be expressed in terms of the about predicate. For arithmetic qualification the operators are to be limited to >, =, <=. The semantics must be interpretable vaguely. The XPath semantics are clearly defined making it a database language. For INEX, an IR language is needed, one in which the semantics can be determined by the retrieval engine. In particular, the meaning of the Boolean operators ”AND” and ”OR” is to become loose and vague. Multiple target elements is to be deprecated. Queries can specify only one target element. Queries with unspecified target elements are to be added. In these queries the retrieval engine is to choose the most appropriate target element. Equivalence tags are to remain, but are beyond the scope of the query language. 3.2 Syntax and Semantics Work is going on to create a detailed description of a query language for INEX 2004. We will mention the most important features here but the full details are beyond the scope of this paper and should be covered in the topic development guidelines. For the CO topics there is no change from last year. For the CAS topics we will only discuss the topic title. Other fields do not change between years. The CAS title queries can take two forms