[osis-core] Wrapping up?

[Troy A. Griffitts]

Hey Todd,

	Sorry for the delay.  Here are my understanding and thought while we wait...

> 1) osisID is for self identifying and is never a range.

yes.

> 2) osisID is always an identifier that fully describes the fully body of
> text it contains.

not sure about this.  I don't think we're finalized a decision on how to 
self-identify some of the more contemporary texts that versify by 
paragraphs. e.g. "This paragraph is Mark 1:1-9"



> 3) higher level "containers" like <div>, <p>, <lineGroup>, <list>, etc..
> will have an optional identifying attribute that deferrers from an
> osisID in that it MAY be a range.  These containers will also have an
> optional osisID attribute for the cases where they purely contain larger
> grain reference like a book or a chapter.

Not sure I understand this completely.  I do understand osisID used for 
higher level (in the context of versification system) of 
self-identification.  e.g.

<div osisID="Mark">The Gospel According to Mark
   <div osisID="Mark.1">Chapter 1
     <verse osisID="Mark.1.1">
The beginnning of the Gospel of Jesus Christ, the Son of God
     </verse>
...
   </div>
...
</div>

I don't understand the 'MAY be a range' that you have stated above.
Did we decide it would be ok to FORCE a complex reference system 
resolution framework in this first OSIS release?  There is a big 
difference between resolving a reference of a purely string-match 
schema, as opposed to the what I think you are suggesting in this #3 item.


> 4) osisID is mandatory on <verse> elements.

sure.


> 5) all other references will use the <reference> element with an
> appropriate type or type/subtype value.

other references?  Not sure what you mean 'other references'.  My 
understanding is that <reference> is the "I'm pointing to..." 
counterpart of the "I am the..." osisID


> 6) references, osisID, and container ids (see #3 above) all take the
> same from including the option of a grain with the exception that an
> osisID may not have a range.

not sure.  I still don't understand this 'container id' thing.  Maybe I 
should go back and reread the archives to see if I missed something.  My 
inhibitions are still such that I believe allowing such a mechanism will 
drastrically complicate implementations for a first level of OSIS support.


> 7) either a reference system or a reference system/work pair must be
> specified in references, osisIDs, and container ids.  The absence of any
> specification implies the default.

reference system: yes.  But are we forcing a 'work' also?  Or do you 
just mean that _Any_ would be included in the set of valid 'work' defaults.



> 8) a default reference system or reference system/work pair must be
> specified in the header.

yes (provided above stipulation on work is true)


> 9) osisIDs may be from more than one reference system.

yes.  Bob specifically stated that he uses this to markup his texts with 
more than one reference system.  I think he's going to have a very hard 
time now that verse is no longer a milestone.  This case was his support 
that he voiced publicly at the Rome meeting justifying our decision (at 
that time) to make verse a milestone.


more (after lunch)...

_______________________


> 10) the form of a reference and a container id is as follows
> [referenceSystem[(work}]:]simpleReference[@grainType.grain][-
> simpleReference[@grainType.grain]]
> examples:
> Bible.KJV(Bible.TEV):Gen.1.1@char.44-Gen.33.3@char.55
> Bible.KJV(Bible.NASB):Gen.1.1@char.44
> Bible.KJV(Bible.TEV):Gen.1.1@char.44-Gen.33.3@char.55
> Bible.KJV:Gen.1.1-Gen.33.3
> Bible.NRSV:Gen.1.1
> Bible.TEV(Bible.TEV):Gen.1.1
> Bible.Todd(Bible.TEV):Gen.331.a
> Bible.KJV:Gen.1.1
> Gen.1.1
> 
> Bible.KJV:Gen.1.1@char.44 (This should not really be allowed because the
> grain is meaningless outside of the context of a specific work.  But I
> would propose that we ignore that detail in validating the form for
> now.)
> 
> 11) the form for an osisID would be as follows
> [referenceSystem[(work}]:]simpleReference[@grainType.grain]
> 12) prev and next attributes of <verse> take the same form as the osisID
> 13) an osisID must ALWAYS be unique and may never be a range.  If there
> is a many to many, one to many, or many to one relationship between a
> verse element in a document and the verse identifiers defined for the
> "preferred" "common" reference system then the document MUST use a
> reference system that has a one to one match between identifiers and
> verse elements. 
> 
> Note: The two options proposed previously:
>    13.a) The use of a list element of osisID singular ids for the osisID
> attribute.
>    13.b) The using the first "common" reference system id as the osisID
> when there are many "common" reference system verses in a single verse
> element and then put child elements that carry osisIDs for the reference
> ids from the "common" reference system that were left out.
> do only work when there is a one to many relationship between the verse
> in current document and verses identifiers in the "common" reference
> system.  The many to many and many to one cases would not have unique
> osisIDs.
> 
> 14) as demonstrated by the osisID form an osisID may have a grain.  This
> will allow for unique osisIDs for segmented verse elements.  (The first
> verse element of a segmented verse is expected to not have a grain to
> facilitate finding the "logical" verse by its non-grain adorned osisID.)
> 
> 
> Problems, suggestions, agreement?
> 
> 
> Issues:
> A) Which elements can be segmented?
> B) What form does a reference to an entire work take?  If we keep the
> same form we could reserve a the character "*" to mean the entire work.
> ("Bible.KJV(Bible.TEV):*" for example).  We must continue to have the
> ":" character present to differentiate between a reference within the
> default reference system and an entire work.  I still think that it
> makes sense to have reference to an entire reference system BUT only the
> work is needed (and not the reference system) when referring to an
> entire work.  It seems that the current reference strategy works when
> trying to express the entire set of references in a work or reference
> system but not to reference a work itself.  I don't really like the idea
> of two optional attributes in <reference> and making the single required
> attribute to do double duty does not work.  It seems that we may need an
> additional element for referring to entire works.  Ideas?
> C) Should we allow the defaulting of the reference system for references
> that are not for self-identification?
> 
> Todd
>