[osis-core] osisID proposal

[Harry Plantinga]

On Fri, 2 Aug 2002, Patrick Durusau wrote:

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

I'm not sure I understand this proposal.  If I want to split a 
<div osisID="Matt.1"> into two pieces, would it look like this:

<div osisID="Matt.1" segID="Matt.1@a">...</div>
<div osisID="Matt.1" segID="Matt.1@b">...</div>?

If that's the case, I don't see why the osisID is included in the segID.
That is, it seems to me that one of the following would suffice:

<div osisID="Matt.1@a">

-or-

<div osisID="Matt.1" segID="a">

-Harry

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