[osis-core] osisID proposal

[Patrick Durusau]

Guys,

Great discussion on the osisID and segments!

After finally getting a refrigerator (they no longer have mini-bars and 
wanted $25 per day for one!) and dialup (sorry no high speed access) 
Internet, I was able to turn to the posts from today.

The examples and samples were very useful!

Propose that we adopt the following syntax for osisIDs:

Work:osisID

The Work portion, inherited from earlier in the document (yes, need to 
specify a syntax for that as well but just looking at osisID now).

osisID is an indentifier according to any standard reference system, no 
more or less.

Examples would include: Matt.1.1, Gen.2.1, etc.

Note that the Matt 1:2-6a in CEV is not an osisID or reference system 
but a reference to a foreign reference system.

Containers can have entire portions that would be separate parts in 
another reference system, such as a paragraph that has multiple whole 
(or partial see next point) verses. In that case, the osisIDs would be 
listed in the osisID attribute as: osisID="Matt.1.1, Matt.1.2, Matt.1.3".

In cases of a portion of a container from another reference system, the 
osisID should have the standard identifier for container, i.e., Matt.1.6 
as part of the osisID. In such cases, the user should also include a 
segID that identifies the portion of the container, such as 
segID="Matt.1.6@a".

Reasoning:

The osisIDs are always what is expected from the standard reference 
system identified by Work. That allows users to rely upon their 
expectations on what will be matched by a standard query.

Note that the second part of the portion would be found on a search for 
Matt.1.6 (since two elements now have that as a part of the osisID) 
which is what should be returned without further processing.

The semantics of segID (Todd's splitID) indicates that it is a segment 
of the portion that occurs prior to the @ sign.

Should document in prose the use of @ and the segment portion, and 
suggest that ordering is implied. (An added bonus is that is would allow 
reordering of texts, although use of that feature would probably beyond 
the average user.)

Note that all elements can have osisIDs and that to allow the recording 
of multiple Matt.1.6 osisIDs, we are obviously talking about data type 
NMTOKENS.

Two questions:

1. Does this accurately summarize the discussion on this issue?

2. Assuming I can turn this into prose that accurately reflects the 
foregoing, does this resolve the osisID syntax issue? (Guess I am asking 
for votes on this segment of the reference syntax issue.)

Assuming that we are all happy (or can at least tolerate ;-) this 
solution, can we move to osisRef syntax? (and afterwards to Work?)

Issues on osisRef:

Assume basic Work:osisRef tracks the foregoing on osisID with the 
following differences:

a. osisRef supports a range operator

b. osisRef supports a grain operator

Other issues on osisRef?

(Please use osisRef as subject line so we can keep the issues separate.)

Thanks!

Patrick

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