[osis-core] OSIS_0105:2 non-Bible References?

[Patrick Durusau]

Todd,

Todd Tillinghast wrote:

>This is really a reply to OSIS_0105:2, OSIS_0105:3, AND OSIS_0105:18.
>
>We seem to be uncomfortable or at least not completely settled on the
>issue of "work", "reference", "ID", "IDREF", identifying who-am-I, and
>i-point-at.
>
>I am starting to come over to the Patrick camp on the use of IDs and
>IDREFs (with a few caveats).
>
>Problems I see that we want to solve and haven't cleanly solved:
>1) We want to use IDs for the who-am-I case.
>
Yes, but this is only relevant for verse, chapter, book, milestones. A 
<p> for example, that contains Matthew 1:2-6a is not who-am-i = 
Matthew.1.2-6a. Rather, it is <p id = "para_2" reference = "Matt.1.2" 
referenceEnd = "Matt.1.6a"> assuming that both reference and 
referenceEnd are datatype IDREF and those IDs exist in the  document 
instance. (You could use Matthew.1.2-6a as an ID, meets all the 
qualifications for a valid XML name but is just a string, has no 
significance other than being different from every other ID string in 
the text. Probably not good practice as it will encourage people to get 
into "legitimate claims" for IDs type problems. IDs are a mechanism for 
use with processors, requesting fragments by ID for example based upon 
the response to a query that returns the IDs of all matching paragraphs, 
etc.)

>
>2) There are cases where two (or more) elements could legitimately claim
>the same ID.
>
Assuming that elements contain (or mark the beginning and ending of 
segments as with milestones), unique portions of the text, how can two 
elements legitimately claim the same ID? (Apart from the restriction 
that all IDs must be unique.)

>
>3) We want to have a "generic" reference structure, but also want to
>validate references to the Bible (and possibly other works) for a more
>restrictive structure.
>
Yes, but see suggestion below.


>
>4) We want to use the behavior of IDREF when use a reference to point at
>an element either in the same document or a different document.
>
No, IDREF is only within a document instance (including any included 
documents), else how is the parser to decide if the IDREF is valid? Can 
decide if a reference is valid against a restriction, however.

>
>5) We are struggling with the "work" structure both because it
>represents the work and in some (but not all cases) the reference
>system.
>6) Our reference structure has no way of requiring "work" be indicated.
>
See suggestion for using "work" to create unique strings for references 
below.


>
>Solutions:
>1) Derive a ReferenceType from both xs:ID and xs:IDREF.  This will give
>us the two building blocks that we want to work with.
>

>
>2) Declare that start milestones are the elements that use the ID for
>references and that end milestones use IDREFs
>
No, this was the problem that came up late last week. Milestones had ID 
and had reference declared as ID datatype. Not valid (at least according 
to IBM)

Need to separate reference and ID. Not the same notion, although we have 
been allowing ID on verse milestones to act as an implied reference. 
More for ease of coding than anything else.

In the latest revision, which you will see before tonight,  milestones 
have ID and IDREF to make it clear when one is making reference to the 
other.

>
>Eg: <p reference="John.1.1"><verseStart marker="John.1.1"/> verse text
><verseEnd marker="John.1.1"/> 
>Where the marker attribute in <verseStart is derived from
>IDReferenceType which is derived from ID AND
>The marker attribute in <verseEnd> is derived from IDREFReferenceType
>which is derived from IDREF AND
>The reference attribute in <p> is derived from IDREFReferenceType which
>is still derived from IDREF.
>
>(marker in <referenceStart>, <chapterStart> and <bookStart> would also
>derive from IDReferenceType)
>(encoders would have to decide between using <referenceStart> and
>[<chapterStart>, <bookStart>, and <verseStart>] strategies for
>milestones.)
>
>3) In order to solve the problems with work, reference system, AND ID
>ambiguity, "work" would be abolished.  If the IDREFReferenceType points
>to an ID in the same document then let it simply say
>(reference="John.1.1") if the IDREFReferenceType points to an ID in a
>different document the (reference="Bible_TEV.xml#John.1.1").
>
See above on IDREF pointing outside the document instance.

>
>4) Allow the marker in a start milestone to either be an
>IDREFReferenceType OR IDReferenceType so that the milestone can point to
>an externally defined reference system.
>
If a reference system schema is added to OSIS, then could validate such 
references but not as ID/IDREF.

> 
>5) Have documents outside the documents being encoded define the set of
>IDs that are the reference system being used within the documents.  The
>Bible_TEV.xml file in #3 above is an example of a file that defines the
>set of reference IDs.  This way ALL IDs are validateable AND this
>solution works for all types of references and does not leave us with
>one strategy for Bible related references and another one for "other"
>references.  Further the "id defining" external documents can also allow
>for "centeralized"/standard reference naming and strategies as well AND
>also provides the mechanism for mapping between reference systems when
>desired but does not force it when not needed/wanted.
>
If I have understood what you are saying (problematic I know but here 
goes) ;-)

What you want is to validate the string that is used to refer to other 
works? Not that it actually points to something but that it is valid 
according to some reference system?

In other words, KJV.YouOnlyLiveTwice.1.31 would not be a valid reference 
(within a document instance, not commenting on whether such a resource 
exists) according to the KJV reference scheme?

Suggestion: Why not use the reference mechanism we have now but declare 
it to be a union of the compScriptureRef.xsd + other reference systems?

In other words, a reference must match  some prefix (part of the regex 
for that reference scheme) plus the notation for that reference.

Example:

default Gen.1.1 (scripture reference being the default)

Livy.Lives.1.15 (regex forces match on Livy, sort of like a namespace to 
prevent conflicts further down on references)

Unless someone has a serious problem with this I will incorporate into 
OSIS_0106 to appear tomorrow (not in today's release).


Patrick


>
>I hope this makes some sense.  I think a complete example would make
>this really clear.  I can possibly to that Monday night but more likely
>Tuesday.  I have to get to bed now because I will likely be awoken by
>the youngest in about 4 hours.
>
>Thoughts?
>
>Todd
>
>>-----Original Message-----
>>From: owner-osis-core@bibletechnologieswg.org [mailto:owner-osis-
>>core@bibletechnologieswg.org] On Behalf Of Patrick Durusau
>>Sent: Saturday, April 06, 2002 10:35 AM
>>To: osis-core@bibletechnologieswg.org
>>Subject: [osis-core] OSIS_0105:2 non-Bible References?
>>
>>Troy,
>>
>>Troy A. Griffitts wrote:
>>
>>>I'll try to tackle commenting on a few...
>>>
>>>>Separate the notion of Bible references from other references more
>>>>generally. For non-Bible references, simply defer by declaring
>>>>
>non-Bible
>
>>>>references to be "x-" and to be treated at some later point with a
>>>>validation mechanism like we have for Bible references.
>>>>
>>>Why are Bible references treated differently than non-Bible
>>>
>references?
>
>>>Per a previous email from Todd, we have a work= attribute that
>>>
>dictates
>
>>>schema (should it be a separate schema= attribute?), if we want to
>>>enforce a schema.  Am I not following your thread of thought on this
>>>one?
>>>
>>Sorry, confusion on my part. Did not interpret work (pointing to
>>WorkType) as requiring validation to another (as yet proposed schema).
>>
>>Seems to be pointing to a regex? No?
>>
>>Help me here, what am I missing?
>>
>>Patrick
>>
>>
>>--
>>Patrick Durusau
>>Director of Research and Development
>>Society of Biblical Literature
>>pdurusau@emory.edu
>>
>>
>

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