[Ex-plain] Attribute Searches

Robert Sanderson azaroth at liverpool.ac.uk
Thu Apr 11 15:51:42 CEST 2002


> > search = true PROX 0,equals,element,false,false
> > (
> >   (
> >     attributeType = 1 PROX 0,equals,element,false,false
> >     attributeSet = XD PROX 0,equals,element,false,false
> >     attribute = 3
> >   )

> I'm sorry, I don't understand your notation here.  Can you recast it
> in (say) Index Data's PQN notation?  Or anything that maps cleanly to
> RPN?

I just took it out of the standard.

I was expanding the attribute set to include attributes for attributeset 
and attributetype.  As an implementor I agree wholeheartedly with Ralph's 
comment that it's much easier to do search for things in the record.
If you don't need to add specific term handlers then so much the better.

So in the notation above I just named the terms rather than specifying non 
existant attributes in the explain-- set


> 	        AttributeSet = Explain--
> 	        type = 1 (access point), value = 7 (attribute)
> 	        term = "XD-1:1=3" (cross-domain "name")

And this is where I disagree. This should be, IMO, three different access 
points PROXed together, one for each of attr set, attr type and attr 
value.


> So the whole search would look like this:

> 	@prox 0 0 0 3 known 8
> 	    @attr Explain-- 1=7 "XD-1:1=3"
> 	    @prox 0 0 0 3 known 8
> 	        @attr Explain-- 1=7 "BIB-2:2=2"
> 	        @attr Explain-- 1=7 "BIB-2:12=aut"

Right.  Just example out the term into three searches for
attributeSet/attributeType/attributeValue  all proximitied together.

So, as a guess (our syntax is vastly different)

@prox 0 0 0 3 known 8
  @attrset Explain-- @attr 1=100 "true"           # search access point
    @prox 0 0 0 3 known 8
        @attrset Explain-- @attr 1=9 "BIB2"       # attr set access point
        @attrset Explain-- @attr 1=8 "12"         # attr type access point
        @attrset Explain-- @attr 1=7 "aut"        # attr value access point
    @prox 0 0 0 3 known 8
        (etc for the other attributes)


> > But we (obviously) need access points for attributeType,
> > attributeSet [...]
> All handled as a part of the single "attribute" access-point: see the
> part of

I -could- (I think) implement this, but it's a significant pain.  If it's
a significant pain for me, it'll be a significant pain for others as well,
I expect.  I really can't see anyone implementing the current way if it's 
optional as it's almost certain to be a big ass pain in the neck.

Also what if you want to search for attributeSets by themselves? EG find
me databases that support BIB2 searches, regardless of which searches they
support?
Useful for determining how widespread ZTHES is (or any other attribute 
set)


> > [...] search, scan and sort. As well as authentication required,
> > protocol, version[1], and so forth.
> Yeah, I guess we could add all these.  Can't say I'm getting up a lot
> of enthusiasm about it until someone has an actual need, though.  I
> don't want to blundering straight into the "Explain Classic" trap of
> defining a lot of extra functionality that no-one really uses, though.

Chalk me up as a need then.  I don't have an SRW client, so couldn't 
handle any databases which were returned to me that are SRW.

For our harvester, I need to know if a database supports scan and search.

> > 1: I propose a 'version' attribute on serverInfo in the same way
> > that protocol is on it.  Equally we could call it protocolVersion,
> Sounds OK.  Let's spell it out, though, as "protocolVersion".

Okies.

-- 
      ,'/:.          Rob Sanderson (azaroth at liverpool.ac.uk)
    ,'-/::::.        http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::.      Special Collections and Archives, extension 3142
,'---/::::::::::.    Twin Cathedrals:  telnet: liverpool.o-r-g.org 7777
____/:::::::::::::.              WWW:  http://liverpool.o-r-g.org:8000/
I L L U M I N A T I





More information about the Ex-plain mailing list