OSIS TECHNICAL COMMITTEE MINUTES

May 24, 2003

TC members present:
Steve DeRose, BTG, chair
Kees Deblois, UBS, vice-chair
Patrick Durusau, SBL
Troy Griffits, Crosswire Bible Society
Kirk Lowery, Westminster Hebrew Institute, secretary pro tem
Mike Perez, ABS
Todd Tillinghast, ContentFrameworks.com

Others present:
John Walker, SIL
Darrel Eppler, SIL
Chris Little, Crosswire Bible Society
Nathan Miles, UBS
Nick Garbidakis, ABS

Issue: What to do with slight extensions to reference systems?

It would be nice to not have to define a whole new reference system.

• We could allow just adding "a," etc., like Matt.1.6a, but cross-document conflicts

• could allow extending the system, with another level (s?), like Matt.1.6.a:

• could tell it's a local exstension because it's got too many levels

• except that some refsystems may have non--fixed # of levels

• except that you might want to do a chapter intro like Matt.1.Intro

• Workaround 1: different delimiter?: Matt.1.6!a

• Workaround 2: make it a grain: Matt.1.6@id[a] or Matt.1.6@ext[Intro]

  Nice and intuitive. it *is* an extension beyond the refsys but you might want to use a grain to be able to measure relative to an extended id indep motivation: @s[Hope]@cp[2] is well-defined and points to the 'o'.

  Constraint: the ext/id grain type can occur in osisIDs (but s and cp can't)

  This argues for a different delimiter to separate the extension portion.

• Troy (later): can you create purely private labels by using ! at top level?

  Consensus is, it's allowed; they are defined to not work across books.

  Should be able to use such a local extension when referring from another doc, if you're explicitly citing that work that has the local extension.

• When matching for an extended id fails, or when falling back to a different version, you drop the local-extension suffix the same way you drop a grain.

• Question: should we provide a way to use s[Hope][2] to get the 2nd instance of "Hope". Yes.

• How do you count instances? For example, what if there's another "Hope" in a note (likely in a catchWord). Do we require the functionality to point to a "Hope" in a note? Do we want to be able to osisRef to things like section Headings?

  DECISION: Notes don't count.

• The content of catchWord is not canonical.

• osisID is permitted on non-canonnical elements.

• 3.2.5: If you want to embed a blockquote in a paragraph, do so. No continued paragraph markup. Warning: LinguaLinks had a lot of embedding, and users got confused -- all gone in FieldWorks. Similar with line groups....

• 3.2.7: For example synoptic parallel pointers.

• Best practice: put such refs in title type="parallels" and "seealso" and extensible (we already added psalm yesterday.

• 3.2.8:

  We're just trying to do simple dictionaries, such as embedded in a Bible's back matter. CEV has oddball case of a dictionary that has many topical sub-dictionaries. these are divs of type glossary.

  Use entry not div for the individual entries; add bare minimum set of tei dictionary markup: at least sense, pronunciation

  Cf xsem -- add 'bookGroup' type for div, which is recursive. Drop div type=testament and div=canon.

  Best Practice: top level divs would be:

  39 OT
  12 RCC books
  n orthodox ones
  27 NT

no -- encodes denominational biasas

We can have names for big traditions, and a header can label which one: prot, prot-ot, nt, cath, orthodox, hebrew, inter-confessional, nt+psalms synoptics. Should be specified in <work>.

[[for later: may want to declare these book lists as PSI]]

• 3.2.10: What about scripture portions? Need a distinct <work> declaratioin. A unique identifier. If there's a PSI that work points to, then if you match you're ok. Prose descr lets human determine if it's what they want. in work dcl, in identifier you point to psi that says the scope. local system ref

  <what-i-contain>
  <reference osisRef=""/>
  ...
  </what-i-contain>

  It could prevent big long lists by allowing the standards <what-i-contain standard-book-group="nt+psalms">

• Does osisRef allow book ranges? todd no due to unknown order; others say take order from ref system. Consensus: allow

• Todd: question

• Canonicity: determined by canonical

• Can we mix elements and mileStones in a single document?

• Troy: if we can't mix, it'll all be milestones because of the few crossovers.

• Todd: Can we kill mileStones? At least for verse.

• PRD: if you can mix verse contrainers and verse milestones, then we don't need splitId....

  All BFBS wants is verse text; so want a trivial way to find.

  Todd: want to pull all verse elements to get text.

  SJD: we can't given our basic decision of BSP over BCV

  John: verse elements are making simpler

  If we eliminated verse milestones, how would that help Todd's implementation? If we completely eliminated milestones, then you could get the text via just xpath(//*[@canonical='true'])

• splitIDs are much harder to train people on.

  terminology:
  break = addressing overlap (either split or milestone)
  split = using splitID
  mileStone = using mileStones if we never use verse elements, just milestones, then you'd have 3 or 4 milestone uses: chapter, verse, quote, speech

  Quaker poll:

• Proposal 1: keep q milestones! With q as only milestone. q is not splitID. q elements ok. Everything else that breaks uses splitID.

  problem: ugliness of splitIDs

• Proposal 2: eliminate all splitIDs, add milestone types if needed. and allow mixing element vs. milestone in a document.

  problem: text sibling of mileStones... But retreiving verses may be easier than with splitIDs.

• Proposal 2a: verse/chapter is always a milestone and never an element, plus the constraints of 2.

• Proposal 3: status quo, a free mix of elements, milestones, splitIDs.

• Proposal 4: lose all milestones, and use splitIDs

  Poll results:

  1: 5 can't, 3 can
  2: 8 prefer
  2a: 5 can, 3 prefer
  3: 4 can't, 3 can
  4: 7 can't

  Proposal 2 wins.

  Best practice within Proposal 2: q/speech should be freely element or milestone – there is no consistency requirement other than than, use an element whenever possible chapter/verse will break often.....

  No need to make a rule; since software has to support both, let encoder do what they want.

  But consistency would be nice. Training is mixed: it is easier to teach elements first, then add milestone later when the student is motivated for it; on the other hand, if no verse element, no need to teach it.

  what's the payoff of the best practice? Conclusion: freedom.

  Should we say: make an effort to be consistent in every way? One example, is if you're using verse elements, then only break to milestones when necessary.

• Non-biblical things to deal with at meeting with Harry:

• 'thematic section' kind of like a concordance.

• zondervan niv study bible.

• sidebar guys in study bibles -- like 'questions about jonah', big ones.

• question of how to do with standoff markup

• difference of encoding index via index entries &amp; generation (how to generate text that show up in the b-o-b index, and encoding the index as a separate object.

• need to define schema of some kind for standoff annotations. subset of osis like note; topic maps? rdf? xlink?

• Troy's syntax issues:

• problem of needing multiple values on an attributes -- is ok? <w gloss="en:word|es:palabra">logos</w> and others....

• if we make it an XML list, problem: gloss may have spaces.

• in TEI, like a simplified feature structure.

• <w> isn't up to this; should come under LAWG work.

  In the meantime: Best Practice encoding such stuff until we provide a normative method, is to use "|" to separate them. Recommended to prefix each with a namespace and ":", if namespace is a language, use standard codes.

• can we shorten name of milestone elements to ms/me/m identical to current one.

  Consensus: leave current ones (mainly for Harry legacy) and deprecate.

• rename start/end on milestones to just be mID. probably we were following tei next/prev. old milestone elements remain unchanged.

• milestones is to be synonymous w/ element -- but there are problems:

• can't write an easy query becuase the GI is different. must search for (q | ms type='q')

• attributes don't come naturally along.

• even if we union them all, you don't get full validation (like enumerated attr types.

• Proposal (Troy): instead of using a separate ms/me tags, use empty instance of same gi:

  <q mID=''/>....<q mID=''/>

  problem: you lose explicit distinction of start/end

  We could go back to <q msID=''/>....<q meID=''/>

  easy to teach.... all you tech people for overlap is to add index on start/end.

  big plus: you get the attributes right for free.

  Consensus: Patrick will write up a description, circulate; barring major objection, this is the way to go.

• Release will be called 1.5.

EVERYBODY TRY TO CLEAR THE LAST WEEK IN AUGUST FOR MEETING AT CALVIN PLANTINGA

Assigned work for next meeting:

• want an encoded, dictionary, devotional, bible study guide; sermons, magazine article

• xslt transform from osis 1.1.1 to 1.5

• example PSIs

• topic map;/ external annotation schema

• list of specific works, to be gotten by Troy & Chris, except magazine article, to be provided by ABS.

• authoring in osis and exporting to powerpoint.