[tmql-wg] Proposed new requirement: Ability to produce textual output

[Robert Barta]

On Tue, Jul 01, 2003 at 06:01:20PM +0100, Chris Angus wrote:
> .....................See, for example, 3.3.2 which talks about
> extending the TM common data model in order to be able to represent
> query results.  It clearly recognises that not all query results will be
> topic map, but will also include objects from topic maps, resources,
> strings, etc.

Chris,

But these query results can be definitely be represented as a
(partial) map. There seems not to be a need for another model.

> A significant part of the abstract model for output would equate,
> therefore, to that model.  In addition, I think that there is a need
> for an abstract model (which might just be a further extension)
> which provides a mechanism for driving the process of establishing
> the required physical output from the data that is the result of the
> query (and which is an instance of the output model).  In essence an
> instance of this latter extension would provide the necessary
> information to generate the required physical output from the query
> results, whether the required output was an XTM, some other form of
> XML document, or some other form.

If I understand that correctly, then the result data (following your
abstract model) would then be serialized into some output stream.

What I find difficult here is that queries seem to have two "phases":
First the identification of what is interesting in the map. If the
query can exactly (and easily) specify that then the result is already
created and may be returned.

In some cases I would expect a second phase to be convenient: Then,
when it is not easily doable to identify ALL content simply with
matching. In such cases /navigation/ (or iteration) over matched
content is simpler.

Example:

Find all associations of type 'is-author-of' where 'x' is the
document.  Then _navigate_ to the other role. If that is 'editor' then
output the person's name differently than if that role were 'author'.

Of course you could write two queries: One which matches
'is-author-of' for 'author' roles and 'is-author-of' with 'editor'
roles. But that may look akward in some situations.

I would expect - depending on the query - that both, matching and
navigation features should be in the language. SQL has it, XQuery has
it, some RDF-query languages have it to a certain extent.

Hosting navigational aspects in your abstract model seems to be a bit
difficult.  Also, there is more complication if we allow content to be
generated conditionally: Where do I host the condition?

\rho