On Fri, June 27, 2008 11:57 pm, Stephens, Owen wrote:
[...]
> The key point
> for me is that we need to move from a situation where literals are
> embedded into strings of text, to one where we clearly reference URIs.
Hooray for URIs. I simply think that it would be easier to promote their
use in MARC currently if they are in their own distinctive subfield which
may be repeated if needed. I think that 300 $a $u $b $u $u $u where URIs
follow the relevant textual subfield would be easier to promote than
including them directly inside the textual subfield. In this case, the
URIs do not replace the vocabulary in the textual field but supplement the
traditional textual field.
[...]
>> Many legacy OPACs would have no capacity for parsing URIs in
>> MARC records if not included in specially designated
>> subfields for URIs.
>
> This was one of the reasons why I thought that embedding as a http link
> (as opposed to using RDF - perhaps someone who knows more about this can
> comment). Since the MARC fields we've talk about so far are (I think)
> free text, the links can just go in. What I don't know is how most LMS
> would handle the prescence of markup in the middle of a MARC field -
> would they encode the charaters (I guess they should do) and so render
> as text, or would they just let it go through, and the browser would
> automatically render as html?
>
Most legacy OPACs might not have a problem with your suggested use of URIs
but some would. Whatever the proposal, if you want it to actually be
adopted for MARC 21 then you have to overcome the 'not everyone can do
that' reason often put forward for rejecting a proposal. My suggestion
above may even have that problem to a worse degree but it seems to me more
like what has traditionally been done for URIs in MARC 21.
> This could be a problem, as differentiating between a genuine use of a
> literal < in the field and a piece of markup would be problematic. I
> can't easily see a way around this, and may be something that prevents
> this approach for transition?
>
MARC 21 standards have tended to only approve of URIs in their own
distinct subfields. However, there is a current proposal for using URIs
for relator terms and codes which could be created in a manner very
similar to what you suggested as a possibility. See the discussion paper,
http://www.loc.gov/marc/marbi/2008/2008-dp05-1.html . I would be pleased
to know what was decided for that proposal at the MARBI meeting.
[...]
> I agree - we would need appropriate record editors. However, standalone
> record editors already exist, and it is relatively easy to separate this
> functionality from much of the rest of an integrated LMS (and in some
> cases this already happens - e.g. OCLCs cataloguing client). Records can
> either be inserted directly into library catalogues, or batch imported
> after creation.
>
> I can envisage a couple of ways an editor could work to support the type
> of syntax I've suggested - we could possibly look at some of the better
> XML and HTML editors for examples.
The type of record editors which I have in mind are ones guide the user
efficiently through the cataloguing process with extensive automation
support to ease the cataloguing burden and reduce error. Such record
editor designs are only minorly implemented currently. Record editor
design is a large subject. I do not think using different record editors
will be a problem. I merely meant the greater the effort which would be
required in a free form record editor for a new record type the greater
the need will be to provide record editors which overcome that burden.
That burden is already high because of the inefficiency of free form
record editors in creating very complete high quality records.
> The way I envisage this working is that the URI specified would link to
> a vocabulary, which would include linguistic variations. If you simply
> indexed the original record then you would be left with only the
> linguistic code used. However, if you indexed the original record AND
> enhanced the indexing with variations retrieved from the URI, you would
> have all linguistic variations represented (and the vocabulary could be
> updated over time of course).
We would have to substantially rewrite our underlying indexing systems for
this nifty idea work directly. I like this concept of indexing. Show me
the indexing system which will make this work efficiently. We could still
capture values from the URIs for storing them in a manner that they could
be used by our legacy indexing systems.
[...]
>> > To give an example, when I was working on record matching
>> in UC union
>> > catalog, it turned out that one of the best "clinchers" for knowing
>> > when you had a different edition was the pagination, not
>> the edition
>> > statement (which are counted different in different countries).
>>
> I'm wary of us cataloguing to the extent suggested here. I don't see
> this as the way to solve the problem of FRBRizing data, I can see how it
> works for legacy data, but I don't think that it is going to prove
> economic to catalogue this level of detail. One of the strengths I see
> in FRBR is that it focuses on what we need to record to help people find
> resources, rather than on simply describing the resources in a literal
> way.
I agree that the focus of cataloguer attention needs to shift for economic
reasons if no other. However, I hope that automated acquisition of data
from publishers will be sufficient most of the time along with the use of
para-professional cataloguers to record information which would be an
inappropriate use of professional cataloguers time. Having the extent
recorded once and copied by everyone else helps a user to estimate how
substantive a work may be and thus how appropriate for the detail needed
by the user without examining it unnecessarily.
Thomas Dukleth
Agogme
109 E 9th Street, 3D
New York, NY 10003
USA
http://www.agogme.com
212-674-3783
|
