Date:Thu, 22 Dec 2005 10:33:46 -0800
Reply-To:Metadata Object Description Schema List <[log in to unmask]>
Sender:Metadata Object Description Schema List <[log in to unmask]>
From:Karen Coyle <[log in to unmask]>
Subject:Re: MODS search points
Comments:To: Metadata Object Description Schema List <[log in to unmask]>
In-Reply-To:<[log in to unmask]>
Content-Type:text/plain; charset=ISO-8859-1; format=flowed
Ray,
Since CQL doesn't correspond to particular fields (which I must say
strikes me as being abstract to the point of non-utility, but oh well),
is there any reason why you couldn't produce search points for things like:
keyword
name
subject
These are actually common search points in the language of library
catalogs and other bibliographic systems.
kc
Ray Denenberg, Library of Congress wrote:
>We would like to see developed a set of search points based on MODS.
>
>In particular, this would be used when searching MODS records via SRU
>(though not intended exclusively for this purpose), so in SRU parlance, this
>would be a CQL context set (see "Additional Notes" below).
>
>The SRU implementors will hold a meeting in March, I would like to propose
>(prior to that meeting) a draft set of bibliographic search points based on
>MODS, and I'm asking this group (the MODS list) to help develop it.
>
>To begin, I've listed a set of search points. The list is a first cut and
>needs to be pruned, as I've included most everything. So I would like to
>ask those of you who might be willing to help on this: (1) which of these
>search points are candidates for pruning, that is, they are less- (or not-)
>likely to be searched; (2) which are most likely to be searched; (3) what
>search points likely to be searched are missing. Please note that even
>though I've probably included too many search points, I've also arbitrarily
>excluded several, so I'm hoping that some of you will give this critical
>review.
>
>Thanks for your help.
>
>Ray Denenberg
>
>BEGIN LIST
>------------------------------------------
>title
>title - abbreviated
>title translated
>title -alternative
>title - uniform
>title - sub
>title - part number
>name -personal
>name corporate
>name - conference
>name - part
>name - affiliation
>name - role
>resource type (enumerated)
>genre (controlled)
>place of origin (controlled)
>publisher
>date issued
>date created
>date captured
>date valid
>date modified
>copyright date
>edition
>issuance (enumerated)
>frequency
>language (controlled)
>physical form (controlled)
>reformatting quality (enumerated)
>internet media type
>extent
>digital origin (enumerated)
>abstract
>table of contents
>target audience (controlled)
>note
>subject - topic
>subject - geographic (controlled)
>subject - temporal
>subject - title
>subject - name
>subject - cartographic scale
>subject - cartographic projection
>subject - cartographic coordinates
>subject - occupation
>classification (controlled)
>identifier-hdl
>identifier-doi
>identifier-isbm
>identifier-isrc
>identifier-ismn
>identifier-issn
>physical location
>location URL
>access condition
>part- detail - number
>part- detail - caption
>part- detail - title
>part - extent - start
>part - extent - end
>part - extent - total
>part - date
>-----------------------------------------
>END LIST
>
>Additional Notes. (Which you don't have to read by which may be helpful.)
>
>The SRU protocol specifications are available at http://www.loc.gov/sru/;
>for CQL see http://www.loc.gov/sru/cql/.
>
>CQL calls search points "indexes", actually "abstract indexes" -- "abstract"
>for two reasons: (1) There is no implementation implication -- support of a
>search point does not necessarily require that you implement an index. (2)
>The index does not necessarily correspond directly to an element in the
>record.
>
>In this case, each index *does* correspond to a MODS element, but the names
>are different, deliberately so, in order to maintain this independence -- in
>theory, these indexes could be used to search records other than MODS if
>there is an appropriate mapping. But in this case it should be clear for
>each index what MODS element it corresponds to (if not, then the index is
>poorly named).
>
>Note also, these are *flat* indexes that do not directly reflect the xml
>structure.
>
>CQL indexes are analogous to Z39.50 Use attributes; see
>http://www.loc.gov/z3950/agency/defns/bib1.html#use
>
>The motivation for this effort is twofold:
>
>(1) There are current projects where MODS records are being harvested (e.g.
>via OAI) and the harvested records are then searched. For example see the
>DLF Aquifer project (http://www.diglib.org/aquifer/).
>
>(2) SRU/CQL has not really developed a coherent set of bibliographic search
>points.
>
>Some observations about point (2).
>- CQL has defined a "dublin core" index set. It is useful for some
>applications but of little or no value for bibliographic searching.
>- The Z39.50 bib-1 set is not a good place to start. It began to grow
>out-of-control a number of years ago because of some deficiencies in the
>protocol and more particularly some of the implementations. We've addressed
>these deficiencies in SRU/CQL.
>- There is a Bath profile for CQL which specifies a number of bibliographic
>indexes, but it doesn't seem rich enough.
>- There is also in development a MARC index set - we think that a
>bibliographic and a MARC index set will complement each other, the first is
>abstract and the second is concrete.
>
>Finally, the concept of an "index set" -- a set of related abstract indexes
>(or seach points) -- actually has been generalized into the concept of a
>"context set" in CQL, which is described at
>http://www.loc.gov/standards/sru/cql/index.html#context. A context set in
>CQL is loosely analogous to a Z39.50 attribute set, and an index set would
>be analogous to the set of Use attributes for an attribute set.
>
>
>
>
--
-----------------------------------
Karen Coyle / Digital Library Consultant
[log in to unmask]http://www.kcoyle.net
ph.: 510-540-7596
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------
