[osis-core] Organizing functional requirements

[Patrick Durusau]

This is a multi-part message in MIME format.
--------------982D5C5F637AF39B73475001
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Robin,

This was one of the most productive 3 day periods I have had in a very
long time! You guys really rock!

On the question of organizing the functional requirements:

I will try to shy away from making implicit committments to solutions in
the summary. At this point I think it would be better if I said data (or
metadata) about a document (as opposed to data "in" the document in the
conventional sense) rather than saying "header information should
include..." since there are several ways of recording such information,
of which header like mechanisms are only one. 

I am not promising that I be fully able to avoid markup like language
but will try to both report and summarize as abstractly as possible.

In its rawest form (i.e., no editing whatsoever) I have attached the
notes from our meeting in Dallas. (This will be posted to the password
protected web directory by early tomorrow and I will post the URL at
that point.) All of my edits, summaries, etc., will be on a separate
file so that each version will be an unchanging snap-shot of that
document at that time.

Patrick

Robin Cover wrote:
> 
> Patrick,
> 
> One suggestion for organizing the meeting notes --
> which I understand to be headed in the direction of
> a draft functional requirements document -- would be
> to adopt the general structure of the TEI Guidelines.
> 
> This could open us up to the charge that we have
> a TEI bias (I would be willing to suffer from the
> fallout).  While I have some major criticisms of
> TEI, including especially its applicability to
> "database-driven document modeling/markup," the
> structure of the Guidelines document itself seems
> fairly unobjectionable.
> 
> I do hope we can continue a commitment to the
> notion of modeling requirements at this point, as
> opposed to focus upon markup constructs.  I think we
> succeeded pretty well in the Dallas meetings.
> 
> Robin

-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu
--------------982D5C5F637AF39B73475001
Content-Type: text/plain; charset=us-ascii;
 name="osis.11Oct.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="osis.11Oct.txt"

OSIS: 11 Oct. 2001

Jerry, Troy, Robin, Steve, Patrick

Decision: Our intention is to design a vocabulary and structures that can be expressed in DTD, XML Schema, Relax NG, and not limited by features peculiar to any expression language. 

Decision: As a design decision compatibility with SGML is not a priority. 

Logos:

Headers:

******

Decision: All of Dublin Core +

Identifiers and means of supporting multiple ones and identifying schemes +

******

(DRM: hand off to working group, technical support for syntax, to evaluate proposals from other groups, patch if needed)

Group charged to select:
1. One approach, foreswearing all others
2. anything goes
3. do anything, but have to provide fallback(s) (support of latter required)
4. defined options, plus do anything (support of latter not required)

******

Cataloging data and direct mapping to CIP

	   LC Number, Dewey (what the scheme, value is)


******

div structure for OSIS, will follow TEI/XSEM/Logos use of div structures, such structural elements need not correspond to divisions commonly known as book, chapter, etc. (use of divs to correspond to canonical references may lead to problems with referencing other structures) this does not preclude software from providing functions based on such traditional divisions.

seg element - has a span (not empty element) (to named later)

return to un-numbered div vs. numbered div

******

provide mechanism for re-naming of element type names and attributes (globalization/internationalization)

1. Rename elements/attributes so long as TEI form attribute is use in TEI Guidelines

******

book dec goes to reference group

Canonical refs: one, in TEI sense, declared to be references of a certain type (formally declared) vs. canonical references in the confessional sense of what materials are canonical texts

OSIS: set of identifiers in OSIS namespace, plus others.

Refs: Here I am, Point to me I am about this, Relevant to Me. (three uses of reference)

Must declare a number system for references (may be more than one). 
All references must either say what scheme or default to the document scheme. 

Reference decision:

1. Must declare reference 
2. Or defaults to document declared
3. Or defaults to OSIS default

Logos elements:

Include langUsage/language

tagsDecl/tagRend ? (what are these)

front/body/back - in

div - in - q of number or not, open

head/tail - out

p/quote/figure/list/item/label - in

l, lg, numbered line groups, coordinate with numbered divs - defer to later

fig, table - in

8.1 - out except hi, defer question of rend attribute, retain function of sup and sub

8.2 - out except foreign with lang attribute (script issues, TEI vs. xml:lang)

abbr - keep

Defer discussion of link types (XLink/XPointer) ptr/ref (Logos) down to 8.6

bible - out (element) but need function to declare base document as separate from editorial apparatus (Logos, comments on meaning and usage), use with non-biblical texts

use of biblical texts in notes and other commentary - of literal or paraphrastic usage.

red - out - replace with speaker elements

certainty markup - need to discuss application of certainty analysis to comment on markup imposed on the text (can point to GI, attribute value, etc)

do app. crit. 

field - out

note - attachment to reference in text 

pict/figure - in (that sort of function)

block - defer, sort of floating div outside the hierarchy

milestones: need beginning and ending milestones, by type (cf. validated with schemas, not validated with DTDs)

What types of milestones: pages, book/chapter/verse/quote, generic, line, semi-open set, 

anchor - in

index - out

browser - out

topic - out

In - need to have some sort of index with keywords, use index type, three levels of keywords, arbitrary indexing 

pull in some portion of topicmaps for indexing

need metadata at less than the document level (like revision date on a paragraph, who authored a paragraph, etc.)

metadata could encompass certainty and responsibility as currently modeled in TEI 

***dinner break***following evening session:

On renaming attributes, Robin suggests: form-attr CDATA #IMPLIDED for renaming attributes: 

   Ex: form-attr = "type genre rend print old-new" in old-new pairs

   global attribute on all elements

tagsDecl/tagRend -- pld looks up, sets the default rendering for elements (see following note on hi)

Unresolved question: do we toss all the rendering elements except hi (or similar function) and if we have an element that operates like hi (with a rend attribute) do we retain rend attribute on other elements?

New Issue: Segmentation and alignment of text

Troy wants to "point back to" the original text, wants to link to words in the text and not dictionary entries.

types vs. tokens? (types are entries in a dictionary/lexicon, tokens are words in the character stream of a text? check with Steve on that reading)

Need both inline and out-of-line linking of texts to source materials

Ex. 

<w strong="937">

vs.

<w orig="NA26/JN/1/1/5">

The first can link easily to a lexicon while the second could be harvested for a correlation table.

(pld, note to group, I am not convinced that this is a separate activity of pointing/linking. For some purposes it may be helpful to tell people they are "linking inline" but I am not sure that concept is helpful in terms of developing the linking and pointing we need for such text. Inline and out-of-line have meaning only with fairly restrictive notions of linking.)

***meeting end about 10:30 Central Time***

Friday, 12 October 2001

Most imp. point, re-purposing of data/texts (Ex. language data)

Confindentiality global attribute: by some mechanism

XSEM Notes:

actorDecl: ? Question for Eirc ? Song of Solomon, 

book - value - enumerated list of books, fixed list, can map to other values.

no speakerDecl for speaker element

back - ok

blockquote - something like this

Enumerated attribute type should be semi-open and not closed.

bookDecl: functionality wanted, move to ref group

bookGroup: make it recursive 

canon - remove, overlaps with bookgroup, move to prefs file for a particular community, publishing and printing goes to bookgroup, bookgroups nests and have a type

change: keep

tables in general accepted, HTML, OASIS, ISO, CALS

comment - extend to be note type element, with type of note, role of person, change name to express use by translators/consultants

Decision: allow numbered and unnumbered divs, but only one or the other. content model forces proper nesting

Header: physical description in general, cover description is a good example (needs ability to point to images)

date: need more attributes, such as format for expression, but more generally other elements like ISBN

dateline: keep but justify what it is used for

General point, accessiblity for visually impaired viewers, text alts for images,

Notion of placeholder for generated text objects (TOC, index, etc)

figure: need alt (accessibility), attributes, copyright for particular piece of work, Need generalized copyright attribute for other elements, maybe global, 

have metadata that is inherited by all textual objects unless blocked. attribute that points off somewhere else for the metadata. 

collection of bibliographic references? 

floating - non-hierarchical, Logos block, free art work in children's bibles

foreign

Support rich notion of date/time and range of date/time: syntax later

front - OK

gloss - content of the element is always displayable - defer - look at exegetical/philological notes

hand - module for bible publishing phrase level elements (typographic bag)

head - ok

holder - ok

idno - ok

index - ok, what about personal/geographic names

typographic bag - inscription (what is relationship between hand and inscription in Daniel?) how to resolve

introductory - ok

item - needs paragraph, allow block level elements 

**Need at least one example of usage, if not more**

keywords - need concept, publication/translation tool? modules for different communities - 

line - linegroup (too generic ?) - keep, best practices, sample values such as doxology

genre identification - refer to working group, genealogy, doxology, etc.

couplet, triplet, quatrain, not the same as doxology, need to make consistent continium.

list - defer, consider making geneology a separate on it own.

mentioned - ok

name - need key, type as global attributes

note - needs to have paragraphs allowed in it - ancillary, parenthetical information that is attached to something else - needs a better typology - use inherited meta-data maybe

p - ok

parallelPassages - another set of cross-reference notes - helps point for scrolling

part - publishing conventions

translation / publishing / core / 

place - needs key and type - geographic (lat/lon for SVG map) OSIS task - authority list of person and place names (Public Subject Identifier)

publihser stuff

q - quote

reading - keep - need stronger model other than #PCDATA - base string and list of witnesses plus witness list

reftext - ask Eric what does this mean - is it transclusion? 

(do the note construction thing) 

salute - keep

schemedocumentation, etc. goes to working group

sourceRef - ref group

speaker - needs key, 

speech - ok 

startdate - header

studyguide - publishing group

subhead - ok

subtitle - ok

supplied - needs metadata, resp, 

targetRef - ref group

text - root element

title, titlegroup - ok

to - ok

translationstmt - header

translator - header

variant - part of the text (reading was for variant in note, not the bible text) This is what you use for variant app. crit. put with app. crit and reading questions. attachment

verse/verseEnd

versespecifier - to pub group

verserdeclaration - to header

versionabbreviation - how to use - versiondecl - versionstmt

work - header

year - date, date range, etc.

YHWH - rename publishing - G-d

Saturday - 13 Oct 2001

<sync = <a name="" - except that it is using a key (as opposed to ID)

      fold into keys in texts and parallel alignment (point alignment of limited usefulness)

      need pre-defined scheme types (Ex. Strong's) refer to reference group

Word level annotation: need to define specific mechanism, specific reference schemes for Strong's, morphology, lemma - need <w> and predefine attributes - only thing construed as keys, IDREF like things - 

Word level annotation - words have ID, lemma, ana, pos and if declare own pos (x-pos) must include OSIS pos, same for lemma, OSIS must define POS and LEMMA. Question: Should ID on word be in normative form.? Should they be interpretable or just magic cookies?

annotation is just note

attribution, names, dates, unclear - ok

What other genres need work - ? vanilla bible, study bible, modest commentary (core)

index - ok

glossary - recommended structure


added/deleted - as containers are form of DIVs - indicate as attribute 

address simple editorial mechanism: dump to app crit committee - suggest TEI mechanism

header: union of TEI, XSEM, Logos, ThML - Dublin core requrired - core committee 

argument - genre of text

hymn markup - genre object 

Schedule:

End of Monday: send minutes to Steve, Robin, Troy, Dennis, Jerry (15 Oct. 2001)

issue list: number and comments apply to numbered items. Any pending issues, declare all as issues and them some as resolved. #, name, summary, 

Create directory for working drafts/auto-update directory/latest - always at same URL:

username: osis

passwd: osisxsem

Post raw form of notes on Sunday.


Working Groups:

need to decide on pitch

Analysis  standards: done

Business 

Reference Group (Todd) Versification/scripture reference/reference schemes: combined

Multi-lingual/International and Analysis (Scott)

Basic text markup 


Process for working groups:

Comparison table of elements

Steve will do the comparison by end of next week (20 Oct 2001)

osis-core@bibletechnologieswg.org





 

 
--------------982D5C5F637AF39B73475001--