[osis-core] Wrapping up?

[Troy A. Griffitts]

>>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.
>>
> 
>