[osis-core] Reference Syntax Proposal

[Todd Tillinghast]

> Greetings!
> 
> As promised, the long awaited proposal on reference syntax! Thanks for
> all the posts and discussions while I was wandering Europe without
good
> Internet access. Never again! Mainline hotels and/or written
> representations of high-speed Internet access for my next trip!
> 
> 1. osisIDs: Serve as identifiers for the element on which they occur.
> 
> Consequence, no range or range like behavior.
> 
> Can be entered as a list of osisIDs in the osisID attribute value to
> accomodate elements that have verses collected into some container
other
> than then standard book, chapter, cf. Todd's Matthew 1:2-6a would be
> encoded:
> 
> <p osisID="Matt.1.1, Matt.1.2, Matt.1.3, Matt.1.4, Matt.1.5,
Matt.1.6a">
> 
> Note that the Matt.1.6a is allowed because a search for Matt.1.6
should
> return that element as well as the one following, in order to get all
of
> what is considered to be Matthew 1:6 (may have reordering in some
> languages, etc.)
> 
> This is based on the defined behavior for processing being:
> 
> A. Match on exact string match: Ex. Matt.1.6 matches Matt.1.6. If that
> fails,
> 
> B. Match on Matt.1.6.*. If that fails,
> 
> C. Match on Matt.1.6.*.*. If that fails,
> 
> This allows the match to descend as it were the possible divisions of
> the reference without prior knowledge of the divisions. (Quite elegant
> and obviously Steve's idea.)

Disagree with this idea!  The identifiers should be used as they are
"defined" by the reference system.  This has the notion of a GRAIN to it
without using the grain syntax.  If we want to say Matt.1.6@enum:a then
we should say exactly that.  Where we should also say Matt.1@enum:a for
the first part of a split up chapter which is different from Matt.1.a.
(That is unless there is a strange reference system that splits the
first chapter if Matthew into two parts and the has verses within in.
Like Matt.1.a.1 which would be the same as Matt.1.1 as we normally think
of it.)  

Summary:  We should ONLY use identifiers as defined by the reference
system, and not introduce a grain like concept AND should allow the same
exact identifier to be used to identify MORE than ONE element.  (I
suggest a mechanism to indicate that the element only partially contains
what the identifier describes in a previous post.)


> 
> (Harry, I think the Matt.1.1_9 is interesting but dangerous from the
> standpoint of data entry error (shift-hyphen), since we will probably
> have to allow hyphens in osisIDs for some reference systems. So you
have
> a syntactically valid ID that is invalid for a particular type of work
> (Bible) but valid for osisRefs.)
> 
> 2. osisRefs: Have range and grain as previously outlined. Noted in
prose
> that osisRefs cannot point to the element on which they appear, i.e.,
> 
>  <p osisID="Matt.1.1, Matt.1.2, Matt.1.3, Matt.1.4, Matt.1.5,
Matt.1.6a"
> osisRef="Matt.1.1-Matt.1.6"> is VERBOTEN!

What is the osisRef element for?  I thought that we were using
<reference> elements for these sorts of purposes.

> 
> Noting that the enumeration of osisIDs will only occur where there are
> divisions that do not include verse divisions. In other words, any
> container could simply omit the osisID, if desired, where lower level
> containers have osisIDs. It is only the partial case that requires
> enumeration or where lower level containers don't carry osisIDs. I
could
> have startMilestone/endMilestone pairs, segs, verses, etc., that have
> proper osisIDs that resolve as detailed above.
> 
> 3. Steve has suggested that we add startMilestone and endMilestone
> elements in addition to the generic milestone (which should then be
used
> for point (or shadow) references. Having separate elements will allow
> enforcement of a endMilestone attribute only on startMilestone
elements
> (in the sense of an IDREF) and a startMilestone attribute (also in the
> sense of IDREF) only on the endMilestone element.
> 

This sounds like a good addition.  If there are verse identifiers for
these milestones they to should allow for multiple atomic identifiers
within their self-identifiers.
<startMilestone id="Matt.1.1 Matt.1.2 Matt.1.3" type="verse"/>

The reason being that just because you are using milestones does not
necessarily mean that you will have more precise information to divide
the text than you would with <p> or <verse> elements.

> 4. Note that the startMileston/endMilestone with a type attribute
should
> solve the quotation problem that Troy has raised.
> 
> 5. In the listing of osisIDs, can prepend work if you want to have a
> mapping for some purpose between reference systems. This should be
> discouraged in favor of actual mapping tables but allowed as a
practical
> matter.
> 

Agreed!

> 6. Note that the defined processing behavior for osisIDs I think gets
> the point of Harry's most recent posts. Would need to document that
> splitting an osisID means that you have to split all occurrences of
it,
> sorta makes sense if it is a self-identification within a system that
> either all are split or none?

Can you explain what you mean here with an example.  I am not sure I am
clear on you meaning.

> 
> I am going to hammer out some more formal syntax and probably just
post
> it outside the schema tomorrow. Should have the schema posted to the
> group, with docs by late Friday (after I arrive in Montreal, need to
> finish getting some stuff installed on the Linux side of my laptop).
> 
> Hopefully we are close enough that we can see some tests of this be
> early next week? (I am opting for the high-speed access option on the
> room in Montreal so when I am not actually in ISO, OASIS TC meetings
or
> at the conference I will be online. Well, am taking one evening to go
> hear an organ recital with Jim Mason but that should be the only break
> in the week.)
> 
> 7.  I have not looked back at the refsDecl discussion yet, Harry, any
> significant problems on declaring a local name for a resource that
> become the work part of the attribute?
> 

I think I missed the whole issue of refsDecl.  Can you shed some light
on what your current thinking is.

> I think this is an accurate summary of my conversation with Steve and
a
> culling from all your posts but if not, it is error on my part and
> should be corrected.
> 
> Other outstanding things I can clean up in the next release?
> 
> Guys you are the finest!
> 
> Patrick
> 
> 
> 
> --
> Patrick Durusau
> Director of Research and Development
> Society of Biblical Literature
> pdurusau@emory.edu
>