[osis-core] Wrapping up?

[Todd Tillinghast]

> -----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 11:43 AM
> To: osis-core@bibletechnologieswg.org
> Subject: Re: [osis-core] Wrapping up?
> 
> 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"
> 

In this case the "1-9" becomes a verse name in the current reference
system in same way that "4" is a verse name in "Gen.1.4".  Other options
were discussed in recent posts.

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

The case with Mark and Mark.1 you state is an osisID but there is an
other case where there are divs smaller that Mark.1.
(Mark.1.1-Mark.1.12) In this case an osisID can not be used to self
identify itself.  What I am proposing with the container ID is that when
a container can not self id with an osisID that a range based self-id be
provided.  I think that we should retain osisID as a non-range and
continue to provide it for the cases you state above but allow this
secondary self-id mechanism.
> 
> > 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
> 

There was a "cite" attribute and an annotation related attribute in
globalAttributes.  This states that the need that drove theses
attributes and others like them should be accomplished with a
<reference> element.

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

See discussion of container ids above.

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

Yes the absence of a work implies any work.

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