[osis-core] header info format again

Mon, 01 Jul 2002 09:14:26 -0400

Harry,

Thanks for the detailed response! Comments follow:

Harry Plantinga wrote:

>>Is the problem the lack of structure in the creator element?
>>
>>I would (from a TEI background) assume the following encoding:
>>
>><creator type="Author"><name type="given">Alexander</name><name
>>type="family">Whyte</name></creator>
>>
>
>
>I don't believe this would be a practical solution for me (or for OSIS
>1.1).  First, there's a whole lot of complexity in a name.  What are
>the given/family names in the following examples:
>
>St. Bernard of Clairvaux
>St. Thomas Aquinas
>The Apostle Paul
>St. Francis de Sales (or Desales)
>Prince
>
>It would be hard to come up with a suitable set of 'type' attributes and
>rules that would allow you to derive different forms of names, one
>canonical, sort-order and another in the form commonly given.
>
Sigh! Yes, name are complex and my proposed solution would fail for the 
reasons you cite. :-( Sorry, just a quick hack suggestion.

>
>Second, a canonical and short-form of a name are exactly what I need
>(and what I already have). It would be too much work to parse 100s of
>names in that way when I don't really need to.  Whereas the canonical
>form can be looked up in a library's catalog; the Library of Congress
>has canonical forms for all authors.
>
Ah, perhaps a moment of clarity!

When you say:

><creator type="Author" format="short-form">Alexander Whyte</creator>
>  <creator type="Author" format="file-as">Whyte, Alexander
>(1836-1921)</creator.
>
You are not using format in the sense of "rend" but in the sense of 
"abbr" and "expan" (well, not exactly but you get the point) of TEI. 
Hmmm, OK, that should be easy enough to add as an attribute value. 
(Sorry it took so many tries for me to hear what you were saying!) I 
assume it should be a datatype so that we can use the "x-" extension 
mechanism for ones not defined in OSIS?

>
>There are similar issues with other OSIS head elements.  For example,
>keywords. I may have two different lists of keywords, under two
>different controlled vocabularies. So I use
>
><subject type="keyword">Christian Life, Sanctification</subject>
><subject type="keyword">Practical Theology</subject>
>
>I have to be able to say what vocabulary those keywords come from.
>
><subject type="keyword" format="ccel-subjects">Christian Life;
>    Sanctification</subject>
><subject type="keyword" format="LCSH">Practical Theology</subject>
>
>These are examples that have lead me to ask for an optional 'format'
>attribute on OSIS head elements. (Actually, that's not quite true--
>I discovered long ago though years of experience that you need both
>"type" and "format" attributes in <head> data. )
>
>Anyway, adding a "format" attribute seems to me to be a good
>compromise between meeting the needs of bible study and digital
>library software for formatted data and minimizing added
>complexity in the <head> element.
>
This is what tipped me off that by "format" you did not mean "rend." 
What you are saying with "format" is a reference to a classification 
system (public or private) that is not actually part of the document.

Cool!.

Note that I think we need to distinguish between "format" as used with 
creator and "format" as used by subject. I just saw your post suggesting 
role for the creator element. Not sure I would use that as a substitute 
for "format."

Perhaps an attribute "form"  that is documented to be a reference to 
system (possibly outside the document for LC headings for example) that 
govern the content. Sort of like the data typing of schema but without 
the validation mechanism.

(I am not avoiding "format" just to be difficult but because the 
semantics of format are different, at least to me, than form.)

Interested?

Patrick

>
>If there is no format attribute, I'll have to encode additional
>information into the type attribute, e.g.
>
><creator type="firstAuthor-shortform">Alexander Whyte</creator>
><creator type="firstAuthor-authorID">whyte</creator>
><creator type="firstAuthor-canonical">Whyte, Alexander (1836-1921)</creator>
><date type="firstPublished-ISO1234">
><subject type="keyword-LCSH">
>
>I suppose that wouldn't be OK, except that other software wouldn't be
>able to understand the header data without manually revising the
>document for someone else's standards.
>
>-Harry
>

-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu