[osis-core] header info format again

Mon, 01 Jul 2002 22:59:50 -0700

This may be a general suggestion, and may not specifically solve this 
problem, but it seems like we might have other cases where the global 
'type' attribute does not suffice.

In the XML repository engine that I developed for Evergreen, we 
classified documents with a 2 level type/subtype scheme that worked very 
well, e.g. type="ORDER" subtype="STANDARD"

Since we have already conceded to allow generic classification with a 
global 'type' attribute, I have no problem extending it to allow a 
subtype classification.

Suggestion:  Add a global subtype attribute that will allow things like

<creator type="firstAuthor" subtype="canonical">Whyte, Alexander 
(1836-1921)</creator>

Thoughts?

	-Troy.

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.
> 
> 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.
> 
> 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.
> 
> 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