[Ex-plain] Attribute Searches

Mike Taylor mike at tecc.co.uk
Thu Apr 11 18:58:15 CEST 2002


> Date: Thu, 11 Apr 2002 14:51:42 +0100 (BST)
> From: Robert Sanderson <azaroth at liverpool.ac.uk>
> 
> > > 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.

Well, put it back then!  >f'TUMPCH!<

Where's that in the standard?

> I was expanding the attribute set to include attributes for
> attributeset and attributetype.

... unilaterally.  OK, we can discuss that :-)

> 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.

Just to check that I understand what point you're making: are you
saying that when we introduce a search such as "thisServer", we should
introduce a corresponding element that's physically present in the
record?  Sounds stupid to me, but I guess I have no specific
objection if that's how people want it.

> > 	        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.

Well, we've not discussed this yet, have we?  Nowza time.

> > 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)

Not bad, except that PQN, like Type-1 query itself (which it closely
mirrors) only supports binary operations: so you can't have AND(a b
c), you have to say AND(a AND(b c)).  Same applies with proximity,
which is why my search above includes the "artifact" of a nested
proximity operation.  Conceptually, all three attributes that we want
to search for are PROXed together in one go.

So your search would have to look like this:

  @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
          @prox 0 0 0 3 known 8
              @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)

Awful, isn't it?  :-)

> > 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.

Question: do you honestly think people are any less unlikely to
implement this than what's currently documented?  Or is the chance of
either getting implemented so vanishingly close to 0.0 that we're
wasting our time even discussing it?  That's a serious question.

> 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)

Ah, you got me in my voonerables :-)  Yes, I'd love to be able to ask
that kind of question about Zthes (note the capitalisation, by the
way.)

> > > [...] 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.

Uh.  OK.  That's a need, I'll add them to the attribute set at an
appropriate time.

 _/|_	 _______________________________________________________________
/o ) \/  Mike Taylor   <mike at miketaylor.org.uk>   www.miketaylor.org.uk
)_v__/\  "An intellectual is a man who says a simple thing in a
	 difficult way; an artist is a man who says a difficult thing
	 in a simple way" -- Charles Bukowski.





More information about the Ex-plain mailing list