Attribute architecture and nested attributes (path queries?)

I had a question regarding nested attributes in the new attribute
architecture. I was trying to work out the maximal power they can
deliver.

Rather than use numeric values, I will use XPath like syntax with
element names. (Values can be strings after all!)

My understanding is nested attributes will allow me to do queries
such as

    Access Point: /head/title
    Term: Lessons in Life

The attribute list for the access point would list two values ('head'
followed by 'title') for the one attribute type ("1" for Access Point).
I can also do wild paths allowing

    Access Point: //title
    Term: Lessons in Life

That is, search in *any* access point where the last attribute value is
title.

What does the following mean?

    Access Point: //title
    Format/Structure: All these words
    Term: Lessons Life

Do the two search terms have to appear under the same 'title' or can they
appear in different 'title' attributes? (If 'Lessons' appears under
/head/title and 'Life' appears under /body/title in the same record,
should the record match?)

Then, pushing things a bit further, can I say under the same 'author'
access point the 'firstname' access point must equal "John" and the
'lastname' access point must equal "Smith"? 

The following query does not mandiate first name and last name be for
the same author in the record (if there are multiple authors)

	/author/firstname = John
    AND
	/author/lastname = Smith

You need something like a PROX operator with an attribute list:

	/author/firstname=John
    Within-the-same /author
	/author/lastname=Smith

Maybe hijack the 'private' choice of 'proximityUnitCode' of the proximity
operator to specify the leading path length that has to be the same...
Ok, pretty yucky. The current KnownProximityUnits are actually not
very useful as I really want to specify proximity with respect to
the same attribute lists being specified in the query. How about
a third CHOICE under proximityUnitCode being an AttributeList?

Just wondering since nested attributes were put in how far someone had
thought them through. Getting a simple path indexing scheme into Z39.50
would certainly be a nice extension! And much more feasible to implement
efficently than full XPath or XML Query etc.

Alan
-- 
Alan Kent (mailto:Alan.Kent@teratext.com.au, http://www.mds.rmit.edu.au/~ajk/)
Project: TeraText Technical Director (http://teratext.com.au) InQuirion Pty Ltd
Postal: Multimedia Database Systems, RMIT, GPO Box 2476V, Melbourne 3001.
Where: RMIT MDS, Bld 91, Level 3, 110 Victoria St, Carlton 3053, VIC Australia.
Phone: +61 3 9925 4114  Reception: +61 3 9925 4099  Fax: +61 3 9925 4098

Received on Tuesday, 10 September 2002 22:46:23 UTC