On Jan 22, 2004, at 6:46 PM, Karen Coyle wrote:
> I'm thinking along these lines:
>
> Create a <title> complex element that has
> <mainTitle>
> <subTitle>
> <partNumber>
> <partName>
> <nonSort> [although below I'll talk about how I would rather see
> nonSort handled]
>
> Create a <titleOther> element that extends <title> and adds the
> attributes "abbreviated", "translated", etc.
This is nice; I like it.
> As for nonSort, just to be contrary, THAT I would like to see as an
> attribute. I'm uneasy with nonSort just floating around amid a bunch of
> other elements. My definition would limit it to the beginning of the
> string. So:
>
> <title>
> <mainTitle nonSort="The ">Best of times</mainTitle>
> <subTitle nonSort="an ">essay on entertaining</subTitle>
> </title>
This I disagree with, though I cannot explain quite why. When we made
our recent citation proposal to the DocBook Technical Committee, they
rejected our proposal to place content of this sort in an attribute.
They claimed (for reasons I don't understand) that it presents some
sort of processing problems. Something at least to look into.
Admittedly, this is also a question of taste, and I find myself
preferring the element-based approach for content.
> Among the reasons that the free-floating nonSort worries me is that
> implementations may not retain the spaces in the elements (whereas they
> are more likely to in a quoted string), and I think it's easier to
> input
> (just my gut).
Actually, I think that's wrong (though see below). Spacing would
happen in processing, and it's better *not* to code that. This is why
also I am proposing some way to code name abbreviations: because it is
better not to include punctuation in the metadata.
> Note that a nonSort element is not always a full word and
> doesn't always get spaces, such as in 17th and 18th century works in
> French where the apostrophe was not used: Lhistoire.... In this case,
> the nonSort is "L" and there are no spaces; or in Arabic, where the
> nonSort is "al-", as in: al-ʻArabah al-dhahabīyah lā taṣʻad.
Can both of these processing situations be handled with the xml:lang
attribute?
>> A corporate name:
>>
>> <name type="corporate">
>> <namePart abbrev="yes">FBI</namePart>
>> <namePart>Federal Bureau of Investigation</namePart>
>> </name>
>
> I think this is unclear -- you don't know if you have a name with two
> parts - one that's abbreviated and one that isn't, i.e.
> U. S. Department of Commerce
> <namePart abbrev="yes">U. S.</namepart>
> <namePart>Department of Commerce</namePart>
>
> or two versions of the same name, as you have.
Yes, you're right. I think this is the one complaints I would have
about the MODS design. Since there's no wrapper for names, there's no
way to code them right in this circumstance (as there is with titles).
> [Note: I have done a first pass at a version of the authority format in
> what I hope is a MODS-compatible schema, and have given it to LC for
> review. That might be a solution for some of the problems that are
> coming up around names.]
Yes, I knew you were working on it, so part of the reason I'm throwing
the ideas out there now.
>> In the end, I suppose this is how I'd do things if I was designing a
>> new schema:
>>
>> <creator role="editor">
>> <person ID="doej">
>> <name>
>> <termOfAddress>Sir</termOfAddress>
>> <given>John</given>
>> <other abbrev="yes">Q</other>
>> <articular>van</articular>
>> <family>Doe</family>
>> <termOfAddress>Duke of X</termOfAddress>
>> <full>Sir John Q. van Doe, Duke of X</full>
>> </name>
>> <note>some notes ...</note>
>> </person>
>> </creator>
>>
>> The advantage is that role is separated from the person, and person
>> from name, allowing additional elements to be wrapped in there as well
>> that are apart from "names." This is a bit beyond the realm of MODS,
>> though.
>
> Yes, but I like this structure. It gets role out of the name area. That
> actually makes sense in a system with a separate authority file for
> names because the same person (read: same name) will be in different
> roles in different bibliographic records, but is always him/herself as
> a
> person.
Exactly. It actually makes more sense even without the authority
records. It is also compatible with various RDF representations, and
so leaves open the possibility to establish relationships between
bibliographic metadata and other metadata. I suppose it's a bit late
to change things in MODS though.
Bruce
|