[osis-core] Wrapping up?

[Todd Tillinghast]

You are correct in that there was consistent support for multiple
reference systems through milestones in the pre-Rome strategy that
BETTER supports multiple reference systems where the points at which
verses start and end differ between reference systems.

I am clear on the elegance of the pre-Rome strategy.

The point I was making what that if the locations of the starting and
ending points is undeterminable because the translator(s) choose to
translate a block of text in such a way that there are no subdivisions
where there would traditionally have been several identifiers/verse ids
(by one or more different reference systems).  In this case the options
are
1) to take on a role similar to the role of the translator and create
verses out of the larger block of text defined by the original
translator(s).  Currently this could be done using milestones within a
verse that's consistent with the original translation or by making
several verse elements.  If there are more than two reference systems
with differing verse boundaries in addition to the reference system of
the work itself, then new milestones would have to be added in to
support the third reference system.

2) do not take on the translator like role and only attempt to map
between the "standard" reference systems and the structure/work defined
reference system.

I believe that it makes the most sense for each Bible document to
support a "standard" reference system (even if it has these grouped and
fragmented sections of text that don't map nicely to the "standard"
reference system).  And that mappings between reference systems be
created and supported at the desired level of granularity externally
from the document itself.

Todd


> -----Original Message-----
> From: owner-osis-core@bibletechnologieswg.org [mailto:owner-osis-
> core@bibletechnologieswg.org] On Behalf Of Troy A. Griffitts
> Sent: Monday, July 22, 2002 5:20 PM
> To: osis-core@bibletechnologieswg.org
> Subject: Re: [osis-core] Wrapping up?
> 
> >>e.g.
> >><verseStart ref="Mark.1.1" />
> >><verseStart ref="Mark.1.2" />
> >>...
> 
> 
> > Regardless of weather or not milestones are permitted the same
problem
> > exists.  (See discussion prior to Rome, regarding this issue.)  In
> > either case we only have a SINGLE point at which to place an
identifier
> > or set of identifiers.  With the milestones option, there is no way
of
> > determining which part of a paragraph belongs to the individual
> > identifiers from a "standard" reference system.  As a result all of
the
> > applicable identifiers have to be assigned to a single milestone.
> 
> Actually, no, that is not the problem in my opinion.  It was exactly
NOT
> having a SINCLE point that was the previously agreed upon solution.
It
> seems you may not understand the pre-rome method for tagging this
> phenomemon.  In the example above, if a section of text was to be a
> valid reference target for Mark.1.1-2, the above 2 start milestones
were
> to preceed the paragraph and 2 end milestones would bound the text.
> Then a reference to either Mark.1.1 or Mark.1.2 would validly point to
> this same chunk of text.  Does that make sense?  Did you understand it
> this way and I was just missing something in your reply?
> 
> 
> >  The
> > best option here is to allow osisID to be a list of osisIDs.  This
if
> > great for the case where there is one element in the document for
many
> > "standard" reference system identifiers.
> 
> 
> > The trouble starts when there
> > are many elements to one identifier in the "standard" reference
system
>  > or even worse many to many!
> 
> ? Like a reference to Mark.1.1 resolves to many places in the
document?
>   Do we really wish to support this?  Are you saying that we wish to
> allow many places in a document to claim: I am (in the KJV ref system)
> work KJV "Mark.1.1"?  I think this should be explicitly disallowed.
> 
> 
> > <verse osisID="Bible.Todd:Mark.1.1-9" altIDs="Mark.1.1 Mark.1.2
Mark.1.3
> > Mark.1.4 Mark.1.5 Mark.1.6 Mark.1.7 Mark.1.8 Mark.1.9">....</verse>
> 
> Not sure what I think about the list type.  It does remove the
> dependency to resolve ranges, but is still more complex (too complex
for
> XPath) than individual tags.
> 
>  > Further the milestone element can be used
> > to provide precision marking of points where a verse starts and ends
in
> > other reference systems.  In this case the type attribute would
likely
> > be set to type="verseStart" and type="verseEnd".
> 
> OK.  This is EXACTLY my understanding of the pre-rome solution.
> 
> 
> >>They are both doing exactly the same
> >>thing.  There should not be 2 mechanisms to do this exact same
thing.
> >>We should instead just extend osisID.
> >>
> >>Unless there is a difference between the 2, other than the
granularity
> >>to which they can point, then the 2 should be consolidated.
> >
> >
> > The difference is that with a container there could be a simple
osisID
> > OR a self-id that allows a range that the osisID does not.  The
point
> > being that there is very strong benefit in precluding ranges in
osisIDs.
> > This precludes self-identification for containers except for those
that
> > are nodes of the hierarchy of the reference system.  As we are well
> > aware not all nodes of the document hierarchy will coincide with the
> > nodes of the hierarchy of the reference system.
> 
> I'm still not sure on the difference.  Are they both marking the
> possible resolution of, say "Mark.1.4"?  This, to me, is their primary
> purpose, and if you agree on the purpose for both, I believe they
should
> be the same mechanism.  If we're going to force support of the "I am
> this" by ranges, then there is no need for the lesser powerful "I am
> this" (no range).  If you still think otherwise, why?  What benefit,
if
> you support finding a place in a doc by ranges, would you need finding
a
> place in a doc without ranges.
> 
> If you have some other thing in mind, like, for example,  "I am Mark
> 1:1-9, by hey, I'm just commenting on who I am and am not trying to
> declare a hard reference target here.  Keep looking lower for <verse>
> tags for the real reference targets" then I have no objection, though
I
> can't think of what we'd use them for in our software.
> 
> 
> 
> About the rest of this message... I have no problem having some kind
of
> "This doc contains roughly Mark.1.1 thru John.5.25" mechanism.  BUT
the
> danger is relating this mechanism even remotely with osisID (the
target
> of a reference).  I would be confused (may have already been
confused).
> 
> 
> > Why would you need a self-id for a container element that could not
have
> > an osisID?  If the document is small (either part of a chapter or
part
> > of a book but larger than a chapter) then having an mechanism to
> > identify what is in this document would be helpful.  For containers
> > farther down the tree, it is beneficial to know what range it refers
to.
> > This is not necessarily for the purpose of a search/xpath/xlink but
to
> > self-identify.
> >
> > Further, if a larger document is broken into pieces and a skeleton
tree
> > that represents the whole document is created the provision for
self-ids
> > for all container elements provides a reliable mechanism to match
the
> > fragment trees into the whole.  The purpose of this being to provide
> > access to the Bible without having to retrieve an entire version if
all
> > that is needed is a small fragment or several small fragments.  Also
the
> > part that is in demand can be present very quickly by getting the
> > overall tree and a fragment while the rest of the document is
retrieved.
> >
> >
> >>This is my thinking.
> >>
> >>
> >>	Thanks for the discussion,
> >>		-Troy.
> >>
> >
> >
> 
>