Re: Attribute architecture and nested attributes (path queries?)

On Wed, Sep 11, 2002 at 04:06:14PM +0200, Sebastian Hammer wrote:
> 
> Access point = /bibliographic/subject[@scheme='LCSH'], term = "computer 
> science"
> 
> and so forth. Open issues would be how you address this in the search with 
> an atribute set identifier. You could imagine per-schema OIDs allocated by 
> communities who need this type of communication, or a single core OID 
> identifying the practice. The ideal would be an extension of the Type-1 
> query which allowed us to identify an XML schema (or namespace?).
...
> We have server code which supports the practice described here, so if 
> anyone would like to try interoperability, give me a holler or download Zebra.
> 
> --Sebastian

Interesting. A few questions if I may to tease things out a bit.
You say above there were open issues on how to put it into Z39.50,
then you have something implemented - how did you put it into the
protocol? (I was curious to the level of functionality you thought
you would need.)

For example, I could imagine using a 'string' attribute value which
was an XPath expression (you can use string values using 'complex'
attribute values). So you define a special set with a single type
(1 = Access Point?) where the value for the type is the XPath expression.

But you mention another point above which is an XPath expression
with namespaces requires scope information - namespace prefixes
for use in the XPath expression itself. (I did not fully understand
what you meant when talked about XML schemas - you don't need a
schema to evaluate an XPath expression - or is that the logical
schema you want to search - separating logical schemas from whatever
the physical representation of the data is).

Or is the idea that the 'XML' representation is just a semantic model
mapped on to the real physical model (whatever it is, including MARC).
That way, we can just say semantic models should not use namespaces.

I am not (yet!) completely convinced introducing XPath as a means
of specifying access points into Z39.50 is a good thing. Most systems
predefine indexes on particular access points etc. Having a completely
dynamic scheme such as XPath for identifying access points may require
a completely different indexing and query engine to existing systems.
Hence its unlikely any existing systems would move forward to use it.
The alternative is to enumerate all the paths a system will support
so you can use XPath expressions to identify a path, but its really
just a fancier naming scheme (attributes instead of a number have
a really long string - but the Z39.50 server just treats the string
effectively as a name - if the XPath expression is in the list of
supported expresions, great its supported.)

Another option (not debating merit yet) is to *encode* requests using
existing numeric attribute schemes. Client applications may allow users
to enter an XPath like syntax. A new Explain category could always be
introduced containng the information for how to convert XPath expressions
into attribute lists etc. The main benefit is that its not that radical a
change to Z39.50 as is. Another thing is any namespace stuff can be
done by the client when mapping to attribute values. (The namespaces
are almost more like OIDs identifiying the set they come out of.)

So I guess the bottom line is how radical you are willing to get
in terms of a model shift. Internally here, major changes are much
less likely to get up.

Interesting area though.

Alan

Received on Thursday, 12 September 2002 22:08:32 UTC