[osis-core] schema 1.1_003 bug

[Todd Tillinghast]

Harry,

Are you saying that a work should not be tied to a single reference
system.  If that is your point, it is an excellent one!  What this leads
me to think is that we should define works and reference systems
separately
<refSystems>
	<refSystem name="X.Y"> all of the elements to declare the ref
system</refSystem>
	<refSystem name="Bible.KJV">all of the elements to declare the
ref system</refSystem>
</refSystems>
<works>
	<work name="X.Y">all of elements to declare the work</work>
	<work name="Bible.TEV">all of the elements to declare the
work</work>
</works>

THIS IS A REVERSAL ON MY PART WITH RESPECT TO WHAT I HAD POSTED
YESTERDAY.  Thank you Harry for keeping me straight.

I also suggested yesterday that we should allow a work to say that it is
also a refSystem.  On further though this seems like a bad idea.  If we
allow a short hand mechanism now for defining a reference system that
points to a work OR just let the work say it defines a refSystem then we
would have difficultly with backwards compatibility if we needed to add
additional requirements to a refSystem declaration in the future that
don't really belong in a work declaration.

Todd

> Let's see here.  I may want to
>   - refer to Pusey's edition of Augustine's Confessions
>   - refer to another edition of Augustine's confessions using the
>     pusey reference system
> 
> Or, I may wish to pull a passage out of the NIV based on a Vulgate
> reference.
> 
> So I want to have an osisWork and a potentially different refSys
> declaration.
> 
> -Harry
> 
> > The question came up because the schema simply copied the
> > structure of
> > work and works for refSystem and refSystems, the reasoning
> > (such as it
> > was and this was during a conference) being that we needed the same
> > information for you to make a reference to a reference system
> > as we do
> > work.
> >
> > But, thinking about it after Chris pointed to the obvious
> > duplication,
> > what is the added value of having separate bibliographic
> > elements that
> > both point to an internal ID?
> >
> > In other words, once you complete a <work> element, it has a
osisWork
> > attribute. osisText has only one, but that does not mean that other
> > osisWork attributes, such as for osisRef cannot also be in
> > the document.
> >
> > Note that we did not reach the issue of how you declare a machine
> > processable (or otherwise processable) refsDecl, a la TEI.
> > Not that the
> > refsDecl there is machine processable either, but that is
> > another issue.
> >
> > So, if we don't have a refsDecl, with the syntax to declare a
> > machine or
> > otherwise processable syntax for references, doesn't an osisWork
> > attribute value fufill the same role? In other words, I am
> > using it to
> > refer to augustine_confessions.pusey (as an osisWork value).
> >
> > Ah, but if you want to explicitly declare a document's
> > reference system,
> > perhaps you have some special linking or processing, hmmm,
> > wouldn't that
> > be an attribute on osisText? Or do you need more indirection
> > than that?
> >
> > Would you ever want to change the default reference system?
> >
> > I guess I am asking if a refSystem attribute on osisText
> > would do what
> > you need or would more be required?
> >
> > Certainly in 2.0, we need to do some machine processable
> > refsDecl mechanism.
> >
> > Patrick
> >
> > >
> > >At any rate, there should be a way of tying an internal
> > identifier such
> > >as "conf" to an elsewhere-defined reference system such as
> > >augustine_confessions.pusey
> > >
> > >-Harry
> > >
> >
> > --
> > Patrick Durusau
> > Director of Research and Development
> > Society of Biblical Literature
> > pdurusau@emory.edu
> >
> >
> >