> Date: Thu, 24 Nov 2005 16:05:03 +0000
> From: Rob Sanderson <[log in to unmask]>
> 
>>> How do I know that any given SRU interface is to a MARC database?
>> 
>> Explain?  Out-of-band agreement?
> 
> Let me rephrase my objections :)

:-)

> There's nothing -wrong- with creating a marc format specific context
> set with n thousand possible indexes corresponding to field +
> subfield, and if there is an out-of-band agreement as to marc
> bibliographic profiles (which there obviously are) then it's quite
> possible to use the context set in the community where the agreement
> holds.

Precisely.

> My objection is that it would be better to work out what is actually
> wanted, rather than how it is stored, and create a context set that
> would be useful outside of searching databases of marc records.

My philosophical answer is that we should be wary about telling people
what would be better for them.  Sometimes, no doubt, we'll be right;
but we can hardly expect to think of every angle that specialists have
thought of within their field.  As an example, my practical answer is
that no generic-biblio profile can enable searched such as "Tell me
which of my MARC records is using 500a to store notes with the word
'fish' in them".  I am sure there are plenty of librarians with good
reason to ask such questions.

> Then the answer to the original question is Yes, not only do we make
> it easier, we make it that your users don't need to lug around a
> copy of the marc bibliographic tables just to work out what to put
> in the search field.

There are those who would need the tables in order to use DC access
points and who would be more comfortable with the MARC fields!  ("Er,
let's see, how do I say 245$c ... is it dc.author or dc.creator?")

>>> Also, SRU doesn't allow for the concept of a MARC database any
>>> more than it allows for the concept of an XML database, a PDF
>>> database, a JPG database or any other format.
>> 
>> Sure it does.  SRU doesn't say anything one way or the other on the
>> subject, and nor it should.
> 
> The SRW/U model is that there is a collection of records, and the
> search takes place over that collection.  The format of those
> records is not something which SRW/U cares about, so long as they
> can be expressed in XML for retrieval.  So my point is that as SRU
> doesn't have the concept of a <format> database, it can't let the
> searcher know that it is a <format> database.

Sure, sure, we all understand the abstract model, and we all
appreciate its power and flexibility.  By now, we all surely also
understand that sometimes you just don't want those layers of
abstraction.  They are an excellent servant but a bad master.  Bottom
line, some people have databases of MARC records.  If we impose a
philosophy on SRU that _prohibits_ them from being seen as such, then
we _reduce_ SRU's power.  Let's not, then.

> Now you COULD have a database that conforms to a MARC profile, which
> says that marcxml record schema and the marc context set must be
> supported.  But that doesn't preclude records being stored
> internally as JPGs, OCRed and interpreted on the fly, then returned
> as marcxml, for an extreme example.

Well, sure; you could do that if you wanted to.

Let me know how you get on.

:-)

 _/|_	 ___________________________________________________________________
/o ) \/  Mike Taylor  <[log in to unmask]>  http://www.miketaylor.org.uk
)_v__/\  "Two fat blokes in pub / First fat bloke says, "Your round,
	 mate" / Friend says, "So are you" -- my favourite short joke,
	 in Haiku form.