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

[Peter Boot]

And one from Syd:

-------- Originele bericht --------
Onderwerp: Re: [Fwd: Re: [tei-council] Proposal <idno> coverage -SF 2493417]
Datum: Sun, 25 Jan 2009 20:35:11 -0500
Van: Syd Bauman <Syd_Bauman at Brown.edu>

KH> I assume values of @key would be separated by a space character.

Probably, but not necessarily. The value of key= is up to the user.
So it would be possible for a user to decide that the values of key=
would be a colon-separated list of filepaths.


KH> It might also make sense to allow more than one value of @ref so
KH> that you could point to a URI for the author, as in my examples
KH> at
KH> 
https://listserv.indiana.edu/cgi-bin/wa-iub.exe?A2=ind0812B&L=TEILIB-L&T=0&F=&S=&P=876
KH> It seems that having the flexibility to name more than one
KH> identifier or address for an element is a good thing, regardless
KH> of what element it's attached to.

Interesting. This leads to an ambiguity. Do multiple URIs on ref= of
<author> mean that you have multiple name authority records for a
single person or organization that is the author, or that you have
one URI for each of multiple authors?


LB> In either case we offer a choice between <bibl> and <biblStruct>
LB> the only difference between which is that the latter constrains
LB> some sort of order on its children -- but they are the same
LB> unruly bunch.

Essentially true, but also a bit of an oversimplification.
<biblStruct> not only constraints the order, but requires the
<analytic>, <monogr> (and thus <imprint>), and <series> children.
<bibl> not only does not constrain the order, it does not allow
<analytic>, <monogr>, <imprint>, or <series>, and does allow text.


LB> If we decided that <biblStruct> was for the ex-novo-case, and
LB> <bibl> was for the other one, we could separate them a bit
LB> better. For example, we might say that <author> only made sense
LB> in <biblStruct> and that <bibl> should instead offer only <name>.
LB> We could reorganize the current model.biblPart class,
LB> distinguishing those which we permit inside <biblStruct> and
LB> those which we do not.

But then you're also going to want the middle case: bibliographic
records that are being generated (i.e., are not transcriptions but
are somewhat more data-oriented) but for which the creator does not
wish to follow the model of <biblStruct>. This is what <biblItem> was
supposed to have addressed.