[osis-core] Harry on osisID's

[Steve DeRose]

At 09:10 AM -0400 07/03/02, Patrick Durusau wrote:
>Greetings!
>
>On the OSIS menu for today:
>
>1. Index syntax - will add for tonight's release (pending your 
>comments, suggestions)
>
>2. castList syntax - will add for tonight's release (pending your 
>comments, suggestions)
>
>Recall that I need suggested content models for: actor, role, and 
>roleDesc (please try to pick from categories we already have, name, 
>abbr, etc.)


Actor:
TEI makes it a typical phrase-sequence, and has a 'who' attribute 
that I presume  can point somewhere. Of the phrase-seq stuff they 
list, the most useful seem to be: #PCDATA, abbr, anchor, date, 
dateRange, expan, foreign (why the heck is 'gi' in this list???), 
gloss, mentioned, name, orig, ref, seg, sic, soCalled, w (hmm, not 
note?) Some small subset of that, I guess; whatever makes the chart 
look symmetrical?

RoleDesc: TEI has same model for these.

Glancing at the chart, the model in use for <name> looks about right 
-- see any glaring omissions if we just go with that?

>
>3. references syntax - posted the outline this morning, comments? 
>(will add just to give us a discussion point)
>
>4. global subtype attribute - Troy suggested and it does give us 
>more flexibility than simply having type

True; we could also declare the type attribute hierarchical like 
newsgroup names; more general (since not just 2 levels), and one 
fewer attribute; also could match on it in one step in typical style 
languages (for CSS, space-delimited would be even better than dots, 
since it has some construct for matching tokens in attributes).

>
>5. Clean up ID and Pointer language and syntax. Generally, osisID 
>(has implied work, no grain or range, no XML ID syntax 
>restrictions), osisID (has implied work, and grain/range). 
>Unfortunately have used osisID as an attribute name and osisRef as a 
>datatype. Need to be consistent and probably should use both as 
>datatypes and not attribute values. That means that verse would have 
>attribute cite with dataType of osisID.

Ahh, nice small item, that. I presume for the latter osisID above, 
you mean osisRef (oops, just typed isisRef -- that would be an 
interesting choice for us to use...).

>
>Will that be too confusing? I sorta like the osisID but don't like 
>my inconsistent usage in the schema.

Yup; at least, I'm confused.

How about the thing without grains and range is type osisIDtype, and 
attr name osisID; the other is osisRefType and osisRef?

>
>I will post a summary of correct names for attributes and data types 
>along with the new schema. (Plus Word and HTML documentation sans 
>the visual models)
>
>Deferrals:
>
>Harry's request for a reference declaration (TEI refsDecl) to say 
>what valid osisIDs are in a document instance. Steve has suggested 
>that should appear shortly after core. (Question for Harry: Did you 
>see this as a documentation function or one of validation? TEI does 
>the former and not the later.)

I *really* want to see that one appear soon. I'm not sure if Harry 
intended validation (though I thought so); certainly I want this file 
to be able to do that.

>
>Open:
>
>Shadow milestones: see my proposal for mangling the IDs on 
>milestones to make them "shadow milestones." Basically prepend "S-" 
>to the osisID so processors that don't use shadow milestones can 
>simply ignore it, those that do can distinguish from actual text 
>references. Valid usage application dependent.

As noted before, 'yech'. But I could be persuaded (cave early, cave 
often, as they say).

>
>Date: do we want to do datatype validation or simply specify a 
>system? (or simply say date and not worry about date validation at 
>this point.)

I think we validate the calendar names (allowing x-), and don't 
validate the values. In the prose spec, strongly recommend ISO form 
for Gregorian dates.

>
>Namespace: Todd suggests: xmlns:osis="http://www.osis.org" (which I 
>note is available)

See my earlier mail on this; I'd prefer an osis 'directory' within 
the btg domain, since btg is technically the organization, and osis 
is one work product (and core a sub-work-product of osis). if, for 
example, we release standardized names for classical works commonly 
cited by theologians, that would still be a btg project, but perhaps 
not properly part of 'osis'; so we'd make another directory. also, 
i'd like it to say 'namespaces' in the path, just for clarity. are 
people comfortable with something like:

xmlns:osis="http://www.bibletechnologies.org/namespaces/osis/core/1.1"

>
>Alternative ending in Mark: I think this is different from 
>versification issue, similar but different.
>
>Common values for use of <seg> for recording formatting for unknown 
>reasons (as opposed to <emph>)
>
>Versification: indicating a system (cf. my proposal to specify the 
>Oxford Study Bible as canonical and if you vary, map to it. 
>canID="map to" osisID="map from")
>(Crude? yes. Gets us out the door? yes. Can be extended in the 
>future? yes. Harry's suggestion but blame me for the suggested 
>implementation.)

Patrick and I had a phone call on this, and it does seem to simplify 
things; seems like the obvious choices for normative forms are Hebrew 
OT and Greek NT (presumably NA27); only prob is Apocrypha.

Oh, another work product I hope we will be able to generate quickly 
after core, is a mapping declaration file; having one normative 
versification does make that easier, for example we don't need 
stackable mappings, and software doesn't need map-path detection 
(which is probably O(NP) or close anyway...

>
>Assuming that I can get 1 -5 to validate and get everyone a fresh 
>release, can we get some proposals/comments on the open issues so we 
>can put this puppy to bed?
>
Woof

-- 

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