[osis-core] header info format again

Tue, 02 Jul 2002 07:39:51 -0400

Troy,

Troy A. Griffitts wrote:

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

Did you not like the "dateFormat" attribute Harry suggested yesterday? ;-)

Not necessarily saying that we may not need "subtype" but would like to 
know how it would differ from Harry's suggested usage of dataFormat.

Patrick

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

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