[osis-core] OSIS reference and pointers, long reply with examples

Patrick Durusau osis-core@bibletechnologieswg.org
Sun, 07 Jul 2002 10:58:58 -0400


This is a multi-part message in MIME format.
--------------010301060401060707050403
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Harry,

I got tired of my mail reader's behavior and so just saved your message 
and edited my reply in Emacs. ;-)

Attached.

Troy posted a note about the default behavior on osisRef where work is 
not specified. I did not deal with it in the attached text but do think 
it would be a good idea to have separate defaults behaviors for osisIDs 
and osisRefs. With the former, no workID means present work, with the 
latter, no workID and no default for osisRef specified, then present 
work. (I think at some point we have to default back to the present 
document but can provide the option to avoid that behavior.)

I will try to assemble some syntax (with explanations) using Harry's 
names for the concepts perhaps late this afternoon.

Patrick

-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu


--------------010301060401060707050403
Content-Type: text/plain;
 name="osis-references.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="osis-references.txt"

Harry's post on 07/06/02 at 7:37 AM

The long reply! ;-)

A major issue: does a <work> element only refer to an OSIS document that
implements a particular osisIDScheme? 

Comment:

Answer: No, work can define any document, OSIS or not, electronic or not. The workID is a system identifier to the document so identified and forms part of the osisID as defined below.

</comment>

Types of identifiers and pointers:

1.  osisIDScheme -- a dot-delimited string, like bible.lxx.en or
augustine_confessions.pusey. Refers to a "versification" or osisID scheme
defined elsewhere. That is, there must be a document on the
bibletechnologies.org website defining this scheme, or this document must be
declared to define the scheme. For the purposes of the OSIS 1.1 schema, it
is an opaque string, though meanings of dot-separated parts will be defined
elsewhere.

2.  osisIDSchemeRef -- a dot-delimited string, like bible.lxx..en-us, that
refers to any one of a class of osisIDSchemes.  An osisIDScheme matches an
osisIDSchemeRef if all the tokens present in the osisIDSchemeRef match the
corresponding tokens in the osisIDScheme. An osisText server, given an
osisIDSchemeRef such as "bible..en-us", should be able to find a document
with a matching osisIDScheme if there is one on.

Comment:

The osisIDscheme would appear in an OSIS document (on the osisText element?) to identify the osisIDSchemeRef (which I take to be the identifier for a <work> element?

Example:

<osisText osisTextID="bible.niv" (reference to a <work> element in the header that defines which edition, date, etc.) osisIDSchemeRef="bible.nrsv.standard" (which also refers to a <work> element in the header that refers to this reference system).>

The osisIDScheme appears in <work> as a system id that is defined in its children elements to be a particular ID or reference scheme and that ID or reference schema may be defined elsewhere, like in a standard edition of a text.

</comment>

3.  osisText -- a particular OSIS document

Comment:

Yes.

</comment>

3.  osisTextID -- a string uniquely identifying an osisText. It may be a
particular version of a particular edition of Kempis' Imitation of Christ,
Troy's version 3.1 of his edition of the LXX, etc. Perhaps it should have
some internal structure, such as augustine_confessions_1.01. (Or perhaps
versioning is important enough that it should have its own element?)

Comment:

Yes and probably should be separated from duty as identifying the reference system. Just a unique ID for the document instance.

</comment>

4. <work workID="xxx"> -- a header element that identifies a particular work
or any work matching an osisIDSchemeRef (e.g. bible.lxx..en-us) and gives it
an internal workID (e.g. lxx). It may identify by author/title/edition,
osisTextID, ISBN, URL, etc.  It may say "don't care" about some attributes.
[should [work] also have a <version> element by which you can request a
particular version of a work?]

Question:

Does the workID need to be different from the osisIDSchemeRef? For some purposes, like use with osisID (as defined below) I will want to use the osisSchemeRef to mean a versification or other reference system. For other purposes, like osisRef (as defined below) I will want to use it to point to either a class of documents (any NRSV edition) or a particular one.

</question>

5.  osisIDElement -- like a name token, but can start with a digit. Must be
unique within an osisIDScheme. Pagebreak milestones (if present) are
conventionally identified as Page_32, Page_xii, etc. [previously called an
osisID]

Comment:

Yes, and I would anticipate that within any osisIDScheme, it would be unique, although I am sure reference systems that are contradictory or vague do exist. Need to use one that satisfies the unniqueness constraint.

</comment>

6.  osisID -- [osisIDScheme:]osisIDElement. If osisIDScheme is omitted, a
default value specified in an <osisText> attribute is assumed.  Thus, an
osisID says "this element contains the osisIDElement part of osisIDScheme".

Comment:

Yes. 

</comment>

7.  grain -- e.g. cp:32(Hello World). [Whatever the latest grain syntax
allows.] Refers to a finer location within an osisID.

Comment:

Yes.

</comment>

8. osisRef: [workID:]ID@grain[-ID@grain] -- pointer to a location or range
in a text. If workID is not present, the current document is assumed. Note
that the prefix is a workID, not an osisIDScheme. There may not even be an
electronic edition of this work. You might refer to Matt.1.3 in Troy's
version 3.1 of the LXX, Matt.1.3 in any English LXX, or Page_32 of volume 7
of the ninth edition of the Encyclopedia Britannica. If the workID is not an
osisIDScheme, the ID refers to an "ID" (variously defined) in that document.
E.g. if this work is an HTML document, it refers to an element in that
document with that ID. I the work is a print edition, could refer to
Page_vii.

Comment:

Yes, but I would understand workID to be the same as osisIDSchemeRef. In other words, in the header appears:

<work workID="bible.nrsv.catholic"> (defining that versification)

<work workID="bible.nrsv.catholic.oxford"> (defining the work being encoded)

<osisText osisTextID="bible.nrsv.catholic.oxford" osisIDSchemeRef="bible.nrsv.catholic">

noting that osisTextID is identifying the full bibliographic entry for the document instance, the "who am I" of the text

the osisIDSchemeRef is identifying the versification or reference scheme for the work (in this case they coincide or mostly so. could easily have cases, new edition of Augustine for example, where the osisTextID and the osisIDSchemeRef are very different.

In the text itself, I would expect an osisRef to be able to refer to other <work> element defined in the header, for example:

within:

<osisText osisTextID="bible.nrsv.catholic.oxford" osisIDSchemeRef="bible.nrsv.catholic">

I have <reference osisRef="augustine_confessions.pusey:Chapter1.section23.paragraph4"-Chapter1.section23.paragraph6">

But in order to use the workID portion (as defined in Harry's syntax) there would have to exist a <work> element in the header that has that portion of the osisRef. (in other words, there would have to exist <work osisIDScheme="augustine_confessions.pusey"> with whatever details you wanted to record for that work.)

</comment>

 - note: need a <volume> element in the <work> element to specify which
volume of a set? Do we need a way of specifying volume, issue, and page
number for a journal article?

Comment:

Will have to look more closely at Dublin Core but at first blush think that falls within identifier, i.e., <identifier type="volume">55</identifier><identifier type="issue">3</identifier><identifier type="pages">35-45</identifier>

</comment>

 - does it really make sense to have osisRefs to text, print editions? If
not, how do we refer to such things?

Comment:

Yes, even if not available electronically, the pointer is useful for constructing a reading list from the text, particularly since the full references (if you are pointing) occurs in the header.

</comment>

<snip>

------------------issues----------------

Should an osisText have an osisTextID, which is unique for
this text? Should it incorporate a version number or shoudl there
be a separate version element?

Comment:

Yes, probably should define in prose.

</comment>

Should the "osisWork" attribute in <osisText osisWork="bible.lxx">
be renamed something like defaultOsisISScheme?

Comment:

Yes, other suggestions?

</comment>

Should there be a way of saying that this osisText implements/
defines an osisIDScheme?

Comment:

Probably but doubtful in this release. Most of what we have discussed is referencing other osisIDSchemes and not defining our own. 

</comment>


Possible osisText attributes:
- defaultIDScheme
- implementsIDScheme
- definesIDScheme

Comment:

like the defaultIDScheme language, partially because it is clearly saying this is the default and if you want something else, it must be defined.

</comment>

--------------010301060401060707050403--