[tei-council] [Fwd: Re: Proposal <idno> coverage -SF 2493417]

[Peter Boot]

Syd asks me to forward this.

-------- Originele bericht --------
Onderwerp: Re: [tei-council] Proposal <idno> coverage -SF 2493417
Datum: Thu, 22 Jan 2009 17:47:06 -0500
Van: Syd Bauman <Syd_Bauman at Brown.edu>

I have three areas of discussion to contribute.

1. Mixed content
-- ----- -------
I concur wholeheartedly with Lou's aversion to
     <author>
        <idno type="nldai">info:eu-repo/dai/nl/12456454</idno>
        <idno type="openid">https://me.yahoo.com/johndoe61</idno>
        John Doe
     </author>
How do you access the name? If you know there's no other
non-whitespace text in there, you could use
     author/text()[ not( normalize-space(.)='' ) ]
but boy, that feels fragile.[1]

2. author identification number
-- ------ -------------- ------
On the original issue Peter raised, some thoughts jump to mind.

* Who says that key= can't have multiple values? Certainly it can,
   syntactically, since the syntax is entirely up to the user. The
   only thing that seems to stop one from using it this way is that
   the Guidelines refer to its value in the singular ("a coded value
   by means of an arbitrary identifier").

* We have gone to great lengths to develop a lovely mechanism for
   encoding details about a person (or organization): her regularized
   name, other forms of her name, her native tongues, the date she was
   born, the places she lived, when she was married, the awards she
   received, etc. Why is her unique identification number in some
   other database so different from these features that it needs to be
   encoded differently? (That is not a rhetorical question, but a real
   one -- are the use-cases here so different as to render our current
   mechanism -- which would be to point to a <person> or <org> from
   the ref= of either <author> itself or of the <persName> or
   <orgName> child of the <author>, and then use <state> or <idno>
   (currently not allowed) in the <person> or <org> -- insufficient?)

3. encoding of author
-- -------- -- ------
I think this would be a semantic shift for <idno>, but not a cosmic
one, and perhaps quite reasonable. However, it may also require a
small semantic shift for <author>. That element is currently
described in the Guidelines with "... the name of the author(s),
personal or corporate, of a work ...". If we are to insist on a
naming element child, that would have to change.

But personally, I think that would be a Very Good Thing. I always
teach my students to use <persName> or <orgName> (or just <name>) as
a child (or children) of <author> when the author is a person or
organization. If the authorship attribution is *not* a name (e.g.,
"anonymous" or "unknown"), I advise them to put it as the textual
content of <author>. (And correspondingly discourage "[unknown]".)

My logic is that I don't want the computer to have to read the
content of <author> to figure out how many people or organizations
are involved. I point out that with
      <author>Peter Boot and Kevin Hawkins</author>
the simple computer program has no way to know there are two authors.
(Would have to parse out the "and" and to know that you didn't use "&amp;"
or "y", which means it's no longer simple.) But
           <author>
             <persName>
               <surname>Boot</surname>
               <forename>Peter</forename>
             </persName>
             <persName>
               <surname>Hawkins</surname>
               <forename>Kevin</forename>
             </persName>
           </author>
is pretty darn clear. (I personally don't generally bother with the
sub-<persName> components, though.)

Thus I think that <author> should say "I contain an indication of the
entity or entities that bear primary responsibility for the item
being described" without confounding that statement by also trying to
indicate that the method of indication is a name.

Notes
-----
[1] And if you know it's the last thing, you could use
        author/text()[ count(../child::*)+1 ]
     but that doesn't feel more stable at all.