Print

Print


From: "Karen Coyle" <[log in to unmask]>
>  It would make sense to define a MODS search point
> based on titleInfo found anywhere in the document, as well as the
> separate title indexes.

Yes, I agree.  (See exchange with Mike Rylander.)  Or some subset of the
separate indexes, based on which are supported and considered useful to
search.


>  Ditto with names, although names are a bit more complex because
> of their use in subjects: you can have a name index that includes all
> names, you can have indexes for personal v. corporate names, and you can
> separate names between creators and subjects.

Ok so to start, that might support the definition of these search points:

name
name - personal
name - corporate

..... but after that it starts getting complicated.   Should there be
'subject-name' as well as 'subject - personal name' etc.   So part of this
exercise is to list exhaustively all the possibilities and then pick the
ones (hopefully a manageable set) that are useful and implementable.

> I don't see why an index
> point on name would have to include affiliation and role ....

It wouldn't.  You could have a 'name' index and a 'name-affiliation' index.
Different indexes.  In the latter case you would be searching for the name
in combination with the affiliation. However (from Z39.50 experience) it's
difficult to express queries like these, and that's why I think it's
important to decide whether any complex indexes are useful/implementable up
front before expending energy trying to come up with syntax to express them.

> do the
> search points have to be strictly hierarchical?

Do you mean can we have an index for name and a separate index for
affiliation?  Yes of course.  However that won't help if you're trying to
search on a name/affiliation combination.  You could, of course, have all
three.

>I have never seen names
> and affiliations combined into a single index.

And as I've said, if searching name/affiliation in combination is not useful
(or not supported) then we won't define that search point.

> >For 'keyword' I'd be hard-pressed to make any correspondence to MODS.
That
> >doesn't at all mean that CQL shouldn't define a 'keyword' search point,
it
> >just means that it would fit somewhere else in the search architecture.
> >
> >
> Can't it correspond to *all MODS fields*?

Sure could.  Or everything except originInfo, as Mike Rylander suggests. Or
we could have several different 'keryword' definitions. or.....

> Or will CQL have a set of
> generic searches that can take care of this?

That too is a possibility, and right now there are a couple candidates. I'm
not sure they're as well-developed as we might like.   But I think we should
postpone the keyword discussion for now and try to solve it later.

> (I'm a bit fuzzy on the
> purpose of the MODS search points.)

Well I'll try to pull together a few thoughts scattered throughout earlier
messages, for a more coherent purpose:

These would be a set of search points that:

1. would have the best chance of corresponding cleanly to indexes when the
database is mods,  but would also be mapable to other formats, perhaps not
quite as cleanly; and
2. are implementable; and
3. are considered useful for searching.

--Ray