Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#27 nameLink element should not have @ref or @key attribute

GREEN
closed-accepted
Lou Burnard
None
5
2008-09-13
2007-12-17
Conal Tuohy
No

It seems to me that att.personal should not be a
member of att.naming, because this allows nameLink to be used with @key
or @ref as an identifier for a person, something which seems highly
improbable to me, to say the least.

Because nameLink is a member of att.naming (via att.personal), it can
have a @ref or @key to identify the entity being named by the nameLink -
yet nameLink is not in fact a name.

"<nameLink> contains a connecting phrase or link used within a name but
not regarded as part of it, such as van der or of."
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-nameLink.html

For example, this is valid, but, I submit, nonsensical:

<persName>
<forename>Frederick</forename>
<nameLink key="frederick.van-der.tronk">van der</nameLink>
<surname>Tronck</surname>
</persName>

This glitch can be resolved by removing att.personal from att.naming,
and instead explicitly including in att.naming every member of
model.persNamePart EXCEPT nameLink.

I also wonder whether persName itself needs @sort?
http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-att.personal.html

Discussion

  • Lou Burnard
    Lou Burnard
    2008-01-13

    • assigned_to: nobody --> louburnard
     
  • Lou Burnard
    Lou Burnard
    2008-01-13

    Logged In: YES
    user_id=1021146
    Originator: NO

    I agree that it's wrong to have @key and @ref on nameLink. And I think your suggested fix would work. Do other Council members think this is in the category of egregious fixable errors?

     
  • Syd Bauman
    Syd Bauman
    2008-01-13

    Logged In: YES
    user_id=686243
    Originator: NO

    I agree that @ref and @key make no sense on <nameLink>, but is it not a problem that @nymRef is also a member of att.naming?

     
  • Conal Tuohy
    Conal Tuohy
    2008-01-13

    Logged In: YES
    user_id=689468
    Originator: YES

    If nameLink were removed from att.naming, then it would also lose the @nymRef attribute. Is this the problem you're referring to, Syd?

    If so, I would guess perhaps it is a problem. i.e. you might want to encode a Spanish name "Miguel d'Garcés" as:

    <name>
    <forename>Miguel</forename>
    <nameLink nymRef="#de">d'</nameLink>
    <surname>Garcés</nameLink>
    </name>

    Where #de points to the canonical nym (containing "de", "of", etc.).

    So in this sense (of being/having a "nym" with various forms) a nameLink IS a kind of name, even though in the sense of being in itself an effective means of referring to someone, it is not.

    Does the att.naming class need to be split?

     
  • James Cummings
    James Cummings
    2008-04-18

    Logged In: YES
    user_id=612078
    Originator: NO

    At the Galway Council meeting the suggestion was made that att.naming be split into
    att.naming and att.canonical (or similar). att.naming would retain @nymRef and att.canonical would hold @ref and @key. All current members of att.naming would be made members of both att.naming and att.canonical except nameLink which would be a member of att.naming only. (And thus not have @key and @ref.)

    A side benefit of this is that there other elements, which aren't really naming elements, which could benefit from @key and @ref to link to authority files. Specifically <author> and <title> might usefully be members of att.canonical. (A request has been made for this, but I've not opened a separate feature request because it is really dependent on this one.)

    -James

     
  • James Cummings
    James Cummings
    2008-04-18

    • status: open --> open-accepted
     
  • Logged In: NO

    There are other elements, too, that have canonical identifiers ... catDesc for instance needs to link to authories subject headings.

     
  • Lou Burnard
    Lou Burnard
    2008-08-17

    • milestone: --> GREEN
     
  • Syd Bauman
    Syd Bauman
    2008-08-21

    Logged In: YES
    user_id=686243
    Originator: NO

    CT> Is this the problem you're referring to, Syd?
    Yes.

    JC> [suggestion Council discussed in Galway.]

    I think this idea is right on target, and that yes, <title> should be
    members of the new att.canonical or whatever it's called. (Besides
    giving a short-cut to people who want to encode the author's name as
    an <author> without a child <persName> (which I don't like), it also
    permits disambiguation of various entries that all read "anonymous"
    (where <persName> is inappropriate). E.g., you might have 100 texts by
    "anonymous" in your corpus of letters to the editor, but know full
    well some details about some of the authors.)

    But I think this does mean that <docAuthor> also needs to be in
    att.canonicalizable; not so sure about <docTitle> and <titlePart> —
    hard to see the need for it.

     
  • Conal Tuohy
    Conal Tuohy
    2008-08-21

    Logged In: YES
    user_id=689468
    Originator: YES

    SB> But I think this does mean that <docAuthor> also needs to be in
    SB> att.canonicalizable; not so sure about <docTitle> and <titlePart> —
    SB> hard to see the need for it.

    I agree with this.

    And to reiterate - the only other one I can think of which I think should definitely be canonicalizable is <catDesc>. This is commonly used to contain e.g. an authoritative subject heading, something which has a textual form as well as (often) a library control number (a Dewey Decimal Code, for instance).

     
  • Lou Burnard
    Lou Burnard
    2008-09-05

    Logged In: YES
    user_id=1021146
    Originator: NO

    nameLink removed from att.personal at rev 4776. This means it gets none of the attributes @full, @sort, @key, @ref, @nymref -- I can see no reason for it to use any of them, since it isn't really a form of name at all, but a preposition or conjunction. The argument that "de" is the same nym as "of" or "von" seems confused to me: these are translations, not variants (like "Tony" and "Anthony").

    The other points (about att.canonical) raised on this ticket, are partly addressed by rev 4775. Since I haven't added catDesc or docTitle to att.canonical yet I'm leaving this ticket pending for the moment

     
  • Lou Burnard
    Lou Burnard
    2008-09-05

    • status: open-accepted --> pending-accepted
     
  • Conal Tuohy
    Conal Tuohy
    2008-09-09

    Hi Lou

    My point about <nameLink>d'</nameLink> was that it is in fact a contraction of "de" and hence could arguably be linked to a "de" nym.

    Cheers

    Con

     
  • Conal Tuohy
    Conal Tuohy
    2008-09-09

    • status: pending-accepted --> open-accepted
     
  • Lou Burnard
    Lou Burnard
    2008-09-13

    • status: open-accepted --> closed-accepted
     
  • Lou Burnard
    Lou Burnard
    2008-09-13

    I agree that you *could* argue that namelinks needed @nymrefs, but I am waiting for someone to actually make that claim, and produce evidence, before supporting it! It seems more likely that you'd want to include the namelink *within* the name part that has a nymref e.g. <surname nymLink="#DBF"><nameLink>d'</nameLink><name>Urbervilles</name></surname> <surname nymLink="#DBF">Durbeyfield</surname>
    Otherwise you're on the rather slippery slope of treating all sorts of name components (abbreviations, syllables, suffixes...) as names.

    I don't think catDesc needs to be added to att.canonical: that's what <classCode> is for.

    I have added docTitle and docAuthor to att.canonical; this ticket is now closed.