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

[Peter Boot]

Forwarded for Kevin:

-------- Originele bericht --------
Onderwerp: Re: [tei-council] Proposal <idno> coverage -SF 2493417
Datum: Sun, 25 Jan 2009 12:12:22 -0500
Van: Kevin Hawkins <kevin.s.hawkins at ultraslavonic.info>

Syd wrote:
> * 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").

And Sebastian added later:
> in the short-term, I am unconvinced that @key cannot do the
> job for Laurent

Since Laurent wanted to be able to assign more than one identifier to an
author, I agree that changing the definition of @key in the Guidelines
to allow for more than one value would solve the problem.  I assume
values of @key would be separated by a space character.

It might also make sense to allow more than one value of @ref so that
you could point to a URI for the author, as in my examples at

https://listserv.indiana.edu/cgi-bin/wa-iub.exe?A2=ind0812B&L=TEILIB-L&T=0&F=&S=&P=876

It seems that having the flexibility to name more than one identifier or
address for an element is a good thing, regardless of what element it's
attached to.

Also, Lou said:
> It seems to me that one way out of this argument might be to propose a
> new <authorStruct> element, which doesn't permit text, but does require
> the kinds of elements we're all agreed form a sensible part of a modern
> bibliographic structure. Strange that the library community hasn't been
> asking for this all along really. Maybe we should move the discussion to
> TEI-L to see if this would fly?

The SIG on Libraries is currently revising the horribly outdated *TEI
Text Encoding in Libraries: Guidelines for Best Practices*.  Melanie
Schlosser and I are leading the formation of new recommendations for
headers, and we are dealing with such structured author metadata.  I'll
need to think things over a bit more, but I may bring this back to the
Council at some point.

Kevin