- From: Alan Kent <ajk@mds.rmit.edu.au>
- Date: Mon, 7 Jul 2003 09:13:46 +1000
- To: www-zig@w3.org
On Sun, Jul 06, 2003 at 04:29:46PM +0100, Robert Sanderson wrote:
> > (1) Should the attribute archtecture try to fit it with the overall
> > protocol (including things like scan - sort also can use attributes)
> > (2) Ignoring the model I put up, I cannot work out how the AA supports
> > querying on title as a complete value and title as words in a reliable
> > way. It seems like you have to look for about 10 magic combinations
>
> ... the second issue isn't with the architecture, it's with the lack
> of explicitness definitions in the core attribute sets? ...
> The issue is the inability to decipher exactly what some combinations
> of those attributes mean... That sounds like a documentation problem, or
> just bugs in the core attribute sets.
Yes. This is my problem. I guess being more precise, the *architecture*
seems like a good idea - as you say its the core attribute sets that I
have a problem with, and it *may* be purely a documentation issue (but
I am not convinced of this from reading the spec as it is).
> 'Title as a complete value' ... you mean treating it as a single complete
> string, doing an exact match? This looks to me to be UTIL 5=15
> (expasion/interpreation = No Expansion)
When I read the spec on 'expasion/interpreation = No Expansion'
it says
The server may expand the term only according to any
expansion/interpretation values supplied. For example, if this
value is suppied and if 'case insensitivite' is not supplied, then
the server should not assume case-insensitivity. If this vqlue is
not suppliued, the server may, at its discretion, apply
expansion/interpretation values not explicitly supplied.
To me this is saying if specified, a server is not allow to do other
expansion attributes by default - it must do exactly what is supplied.
The other expansion attributes talk about case sensitivity, stemming,
stop words, truncation etc. It does not (to me) talk about treating the
string as a complete value or as words.
Going further, this implies I cannot let the server make default
choices (case sensitive or not) when searching complete value fields?
> 'Title as words' ... And here you mean treating the title as an ordered
> list of words. This seems to me to be UTIL 9=1 (format/structure =
> adjacentWords)
If I look at the draft Bath profile for using the AA (I cannot find it
again on the web just now, so I assume its still the latest draft),
it uses
format/structure = adjacentWords
in exact match (complete value) queries, not word based queries as you
suggested might be appropriate above. Now the Bath profile for Bib-2
that I have is a draft, but it was the only decent set of example
queries and what they mean I could find, and it is the exact opposite
of what you are suggesting.
Further, when you look up adjacentWords in the AA spec, there is no
description at all! There are 3 options listed: AdjacentWords,
AllTheseWords, and AnyOfTheseWords. To me this does not make it clear
that for scanning and querying that using AdjacentWords is a good
choice to use for 'complete value'. To me it sounds like the purpose
is when specifying a query term that has multiple words in it, is it an
AND, OR, or PROX=adjacent on those words?
> What am I missing?
I guess my problem is that I cannot determine from reading the spec if
what you are saying above is correct or not. My reading of what I have
tends me to lean towards your examples being incorrect - but that may
be a fault of the documentation, I don't know.
I still think the Bib-1 approach that Bath ended up with of having
an orthogonal attribute type indicating how terms are extract from records
(completeness) is a good thing. (Note: I don't think Bib-1 got it right
initially, but I think the Bath profile made a good (implicit) choice
here.) I cannot see how to do this in the core AA attribute sets.
Alan
Received on Sunday, 6 July 2003 19:13:55 UTC