[osis-core] scripCom

[Steve DeRose]

As best I can figure this out so far, what I see is essentially these cases:



A: The GNT, KJV, or any other version of Matthew 1:1:

   <verse ref="Matt.1.1">

   This is the "I am" case -- in effect, it means that this text 
claims to be some version of the identified passage, and should thus 
be appropriate as the target of any reference to that passage. This 
is faintly analogous to XML IDs.

B: A link to a particular passage:

   <ref word="Bible.NIV...." ref="Matt.1.1-Matt.1.4">

   This is the reference or outRef case, which specifically means the 
text at this point is *not* claiming to be an edition of the 
identified passage, but a place that is relevant to understanding it 
(or vice versa). This is faintly analogous to XML IDREFs.


One substantive difference between these 2 cases are that for A, we 
have only permitted a single verse-level, non-range reference, while 
for B, we can have the range and grain syntaxes included.

Thus, for A one cannot say this is "Matthew 1:1-3"; if that is the 
case one must encode all 3 verse references there (the looser the 
translation or paraphrase, the more this will happen). The rationale 
for this was ease of implementation for search: on receiving a 
reference to a range, programs do not need to do a, uh, shall we say 
interesting, range-intersection algorithm, because the targets it's 
looking for are always identified in the same form.

I really think this fundamental distinction should remain, for the 
same reason one has ID and IDREF in XML.


I think, though, that we also have two possible subtypes of B:

    B1) This is a link to that passage, intended mainly to get you there

    B2) This marks content that is generally "about" that passage

We'd been thinking about B1 when designing ref: Things like marginal 
cross-references, Thomson chain-references, connections between a 
footnote and a referenced "cf" passage, connections between NT quotes 
and their OT sources, headers specifying parallel passages in the 
synoptics, and so on.

(Now of course, it may be useful to distinguish types such as I just 
listed, too...)

I think B2 was entirely missing until Harry recently pointed it out. 
This would include cases like

"I am a commentary (or portion) *about* Matt.1.1"
"I am a sermon (or portion) *about* Matt.1.1"
"I am a reader response annotation *about* Matt.1.1"
"I am an exposition (or portion) *about* Matt.1.1"
"I am a poeticRendering (or portion) *about* Matt.1.1"

I've intentionally based these examples on Harry's list. I also agree 
that the list should be extensible, presumably using our usual "x-" 
convention (hmmmm, it just occurred to me that since "x" is sometimes 
an abbreviation for Christ, that's a kind of appropriate convention).

If we break it down this way, I'm not sure how Harry's "translation" 
example would fit -- in my thinking, at least, a translation would 
use case (A); unless perhaps it were something very loose, such as 
the Cotton Patch Gospels -- though even there I'd be inclined 
strongly toward A. No doubt there exist some cases on the boundary of 
translation vs. commentary (Readers' Digest Version?).

Some other kinds of "about-ness" that I can think of are:

"I am an application guide *about* Matt.1.1"
"I am a meditation/devotional *about* Matt.1.1"
"I am a course or course notes *about* Matt.1.1"
"I am a theological treatise *about* Matt.1.1"

"I am a text-critical analysis *about* Matt.1.1"
"I am a linguistic analysis *about* Matt.1.1"
    (we could of course allow hierarchy and have analysis.textcrit,
       analysis.linguistic.grammatical, etc)

"I am a doctrine justifying myself via Matt.1.1"

"I am a song based on Matt.1.1"
    (likewise for any other medium: illustration, video, screenplay, drama,...)

"I am an allusion to Matt.1.1"

I've about run out of steam here; I'm guessing that if we cut things 
up at some moderate granularity like this, we can have a list of a 
couple dozen or so types that will be fairly intuitive and fairly 
complete.

I've always liked the idea of hierarchical sub-typeing (like 
newsgroups), where the x- extension can be added at any level (though 
I wouldn't bother validating that via regex unless it's trivial -- 
like maybe 'must be one of our predefined types OR contain "x-" 
*somewhere* in it).

So I guess my proposal would be to keep the verse vs. ref 
distinction, but have an extensible but also extensive set of 
normative types for refs.

I think Harry suggested somewhere that such typed refs would be 
useful on more than just a single element type (<ref>) -- I agree; 
seems like it should go at least on <div> too; probably not down at 
sentence/phrase/word level, though.

Thoughts? Does this approach cover the various concerns that have 
been raised, and give enough distinctive power (assuming we add 
whatever sub-types I've presumably missed?

-- 

Steve DeRose -- http://www.stg.brown.edu/~sjd
Chair, Bible Technologies Group -- http://www.bibletechnologies.net
Email: sderose@speakeasy.net
Backup email: sderose@mac.com, sjd@stg.brown.edu