On Thu, 2006-07-27 at 10:02 -0400, Ray Denenberg, Library of Congress
> > I do not believe that this approach was ever discussed; and in any
> > case it is very much inferior to the simple use of "eq".
> Well first, I think 'eq' is a poor solution, and second, yes we did have
> discussion -- endless discussion (on the Ed. Board list) and while it's
> not productive to rehash it, it's worth highlighting a few conclusions:
> - it is confusing to have both an '=' and 'eq' relation
Which is why we had scr /and/ a semi-magical = that did the right thing.
Now we have one magical =, no scr and eq for equality.
> - but '=' to replace 'scr' is overwhelming favored, so we need an equality
> relation (to replace the changed '=') -- indeed anchoring was discussed, as
> the way string matching is done for bibliographic data -- but an explicit
> equality relation was also discussed
And is fundamentally necessary.
> So, neither '=' nor 'eq' is a solution for equality. As I look back on the
> discussion it wasn't clear that 'exact' was to be depricated.
Well, you wrote it in the list of changes for version 1.2, so at some
point it was clear :)
I don't see why 'eq' is not a solution, though.
> I suggest 'exact' for explicit equality. I think it's better than 'eq'.
It's an arbitrary token that's defined in a context set, not the
'exact' has existing semantics of string equality. If we change the
semantics of it to equality of any sort, then we have ambiguity between:
number exact 1
in the two versions.
Is that a search for 1.0000000 or "1" ? In 1.1, it's always "1". In 1.2
it would be up to the server to determine (unless there's a relation
modifier specifying the term format).
With =, this is tolerable because you can still do the right thing, and
it was semi-magical anyway. But I don't agree with changing the
semantics of exact, which had well defined semantics of string equality.
What's wrong with eq?
Dr Robert Sanderson
Dept of Computer Science, University of Liverpool