Re: Semantic qualifiers in the attribute architecture

> Date: Tue, 26 Aug 2003 09:15:45 +1000
> From: Alan Kent <ajk@mds.rmit.edu.au>
> 
> A hopefully easy question. In the attribute architecture, is there
> any expectation to use 'complex' in an attribute list for the
> semantic qualifier attribute type? In AttributeElement in the Z39.50
> ASN.1, you can specify an optional OID, an attribute type (integer),
> and an attributeValue. The attribute value is a choice of a numeric
> (which most people use) and 'complex' which is a list of
> StringOrNumeric plus an optional sequence of semanticAction values.
> 
> I believe AA semantic qualifiers are unrelated to the 'complex' bit
> (with its 'semanticAction') in AttributeElement. Is this correct?

I've discussed this with Alan in another forum, but I think it's good
to nail down the answer on the ZIG list, too.

To deal with the last bit first, the Attribute Architecture's Semantic
Qualifier attribute-type is completely unrelated to the semanticAction
element in the ASN.1 for complex query terms.

The Architecture envisages that attribute values may be either numbers
(as is common with pre-AA attribute sets such as BIB-1) or strings.
(Or lists containing either or both, but that doesn't concern us
here.)  See section 2.1 ("Attribute Values") of
	http://www.loc.gov/z3950/agency/attrarch/attrarch.html

String values seem to be widely used for attributes of type 2
(Semantic Qualifier) and 12 (Functional Qualifier), and possibly 2
(Language) and 4 (Content Authority) -- for example the BIB-2
attribute set provides sets of Semantic and Functional Qualifier
strings to use with access points.  However, there's no particular
reason why string values should be used for attributes of these types,
nor why they should not be used for other attribute types.  There's
nothing in the AA to stop me defining the Mike-1 attribute set
containing the access points 1, 17, "fruitcake" and 29.

Finally the issue of how string-valued attributes are represented.
The AA never spells this out (though to my mind it's strongly implied
by the part of section 2.1 that talks about sequences), but Alan and I
independently reached the conclusion that there's only one way to do
this anyway: within AttributeElement, the AttributeValue element takes
the "complex" branch of the CHOICE; the contained "list" has a single
string in it, and the "semanticAction" is omitted.

Hope that clears everything up.

 _/|_	 _______________________________________________________________
/o ) \/  Mike Taylor  <mike@indexdata.com>  http://www.miketaylor.org.uk
)_v__/\  "Furious activity is no substitute for understanding" --
	 H. H. Williams.

--
Listen to my wife's new CD of kids' music, _Child's Play_, at
	http://www.pipedreaming.org.uk/childsplay/

Received on Tuesday, 26 August 2003 06:18:39 UTC