[osis-core] Proposed works syntax

[Patrick Durusau]

Harry,

Actually a little of both! ;-)

In the latest version, osisWork and osisID are two separate attributes.

In the header, osisWork is the ID on the <work> element, which allows 
the declaration of things like "bible.lxx.spanish" or "bible.nrsva".

The set of Dublin Core elements allows you to bind the meaning of 
"bible.nrsva" or whatever, as closely or as loosely as you desire to the 
content of those elements. Note that these elements have a "bohu" 
attribute which defaults to "true." This is so we can distinguish 
between simple omission and "I don't care" about language for example. 
The bohu attribute forces the default to "I don't care" if not otherwise 
specified.

Meaning that if all I do is <work osisWork="bible.nrsva"> then any 
osisID with that as an explicit or implied osisWork value can resolve to 
any "bible.nrsva" work  without regard to language, date, etc. If I 
said, "bible.nrsva.niv.us-en" (that syntax is just convention, has no 
meaning other than as a string, the content of the elements control), 
then that as an implied osisWork would mean that resolving osisIDs would 
look for only bibles, only nrsva, only niv, only us-en. It assumes, but 
does not enforce proper use of the reference system found in that osisWork.

It is only partially internal since I think we should offer a basic set 
of <work osisWork="bible...."> in the header both as guides to adding 
such elements to the work and to provide a starting set of such identifiers.

We may want to call this by indirection  so we can update to have the 
list of legal osisWork names for all OSIS documents. (Following Todd's 
suggestion that we keep osisCore abstract and build modules on it.)


Any element can have the osisWork attribute which is declared to be an 
IDREF. This forces the osisWork attribute to validate against the 
osisWork attribute in work. (That sounds confusing, should we change the 
name of the one in the header?) So you get validation to that extent if 
you use osisWork as a separate attribute.

When combining with an osisID, you get osisWork:(followed by the 
osisID). Note that we are not attempting to validate the osisWork here. 
The problem with datatyping was that the patterns could not be easily 
extended by users for other reference systems. Steve and I are talking 
about getting ABS/SBL to sponsor software to do validation of the 
osisIDs for free distribution.

Does that help?

Patrick

Harry Plantinga wrote:

>Patrick,
>
>As I understand it, there are a couple of different models on the table.
>(I'm going
>to assume the osisWork and osisID are in the same attribute; translate if
>necessary.)
>
>Proposal A:
>
>For osisWork:osisID, osisWork is one of a pre-defined set of standards, such
>as
>"bible.lxx.spanish", or an extension, x-whatever-you-please.  If the latter
>case,
>x-whatever-you-please, you have to have in the header:
><work osisWork="x-whatever-you-please">.
>
>Is that a correct understanding of your proposal?
>
>Proposal B:
>
>osisWork is an internal ID with no external meaning.  osisWork always has to
>be defined in a <work osisWork=".."> header element. If it is an externally
>defined
>standard osisID schema, it woudl have to be specified in the <work> element.
>
>Advantages of B as I see it:
>  1.  you don't have to update the schema for new standardized osisID
>schemes
>  2. you can use short internal osisWork ids, such as "conf" instead of
>      "x-augustine-confessions.pusey"
>  3. you can use elements in the <work> element to say what language you
>      want, what edition, etc. You don't have to encode all that into a dot-
>      delimited osisWork id.
>
>Advantages of A:
>  1. can validate standard osisID schemes from a list of legal names.
>  2. it's not necessary to add a <work> element to the header for
>      standardized schemes
>
>-Harry
>
>----- Original Message -----
>From: "Patrick Durusau" <pdurusau@emory.edu>
>To: <osis-core@bibletechnologieswg.org>
>Sent: Thursday, July 04, 2002 11:17 AM
>Subject: Re: [osis-core] Proposed works syntax
>
>
>>Harry,
>>
>>I am working on a somewhat longer post to try to summarize some of these
>>issues but wanted to be sure I understood what you are proposing.
>>
>>Harry Plantinga wrote:
>>
>>>>Seriously, the purpose of <work> is to allow an osisWork attribute to
>>>>reference a value, much like castList allows a reference to
>>>>particular role.
>>>>
>>>>What I was trying to say was:
>>>>
>>>><verse work="bible.lxx" osisID="some reference in LXX">blah,
>>>>
>blah</verse>
>
>>>I thought we were considering a collapsing that to a single attribute,
>>>with an optional namespace-like prefix for teh work identifier, like
>>>
>this:
>
>>><verse osisID="bible.lxx:someReference"> ??
>>>
>>I think it is doable, but note that while we can specify values for the
>>work portion, validation is not a possibility if you want to use
>>
>datatypes.
>
>>Reason? If you want to say, bible.lxx:, bible.nrsva: are OK plus
>>Book.chapter.verse, you have to use the patterns in XML schema. That
>>means that you can't call another set of values, like an enumerated list
>>that a user could extend, to be part of the pattern expression.
>>
>>If validation of the syntax is limited to its form (in other words, not
>>content) then what you suggest (which I think is the latest suggestion)
>>is certainly possible.
>>
>>>
>>>I thought <isbn> <issn> <url> might be a little more straightforward
>>>than <identifier type="ISBN"> etc, but either is OK with me. I was
>>>just concerned that people would use identifier types inconsistently.
>>>Maybe we should specify a few and use the x-extension syntax.
>>>
>>Would not be a problem to put together. Will take a look around and
>>suggested types are welcome.
>>
>>>>So what I am trying to do is provide a way to specify what is meant by
>>>>"bible.lxx" when it appears as a attribute in <work>. Would this not
>>>>give us a way in the initial release to specify several bible.***
>>>>systems of reference? Or any others for that matter? (Extending your
>>>>suggestion and may be way off base so please correct.)
>>>>
>>>What I'm not sure about is how you would use the above system to say:
>>>
>>>"I want an american english version of the KJV" -- where do you say
>>>that it shoudl be a generic "bible"?
>>>
>>In the header there is a language element is where I would specify
>>language (as well as an optional lang attribute on elements).
>>
>>>"I want any edition of the bible.lxx" where bible.lxx is one of those
>>>standardized osisID schemes we've discussed. Do I have to know a title,
>>>publisher, author to fill in?  Or is there somewhere that I can use
>>>a generic osisID scheme name such as bible.lxx, which is defined outside
>>>this document?
>>>
>>>What were the other fancy kinds of bible version specifications from
>>>Rome that I recall someone enumerating on this list some time ago. How
>>>woudl they work?  E.g. suppose I want a bible (any bible) in American
>>>English. I suppose I would use <language>en-us</language> but where
>>>to I say "a bible, any bible"?
>>>
>>Are you saying that I should be able to say (not in syntax but hopefully
>>clear)
>>
>>osisRef - give me Matt.1.1 but only from any English translation? or
>>from a particular translation?
>>
>>Wouldn't that be defined in the header (with some improvements) as I
>>have suggested? In other words, if you have in the header:
>>
>><work osisWork="bible.nrsva">etc.
>>
>>osisRef="Matt.1.1" (assuming work defaults from an attribute on
>>osisText) mean any Matt.1.1 that is using bible.nrsva as a reference
>>
>system.
>
>>If you wanted to specify that your references are to a particular edition:
>>
>><work osisWork="bible.nrsva.niv">etc.
>>
>>osisRef="Matt.1.1" is defaulting to pointing only at an NIV translation,
>>although the software could fall back to some other NRSVA edition
>>
>>Or even to a particular language:
>>
>><work osisWork="bible.nrsva.niv.spanish:>etc.
>>
>>I think the problem is and one of the reason I suggested splitting up
>>most of this into attributes is what happens if someone wants to skip
>>part of the expression? I don't care about NSRVA or NIV but want
>>bible.spanish as my osisWork. Not unreasonable but virtually impossible
>>to validate with datatyping.
>>
>>Now, if we abandon datatyping altogether, user has an example syntax and
>>if they follow it, other OSIS applications will be able to find their
>>materials, don't follow and it won't,   then that is an entirely
>>different story.
>>
>>Maybe the problem is that I keep seeing it as a datatyping problem.
>>
>>>I think we need some way of tying a <work> to a pre-defined osisID
>>>scheme. That was the purpose of my proposed additional attribute to
>>>specify an externally defined osisID scheme such as bible.lxx or
>>>josephus or augustine_confessions.pusey
>>>
>>No problem with referencing an outside scheme.
>>
>> From an earlier post you made today:
>>
>><work refWork="LXX"><osisWork>bible.lxx</osisWork></work> would give us a
>>way of saying "I want to use the osisID scheme of bible.lxx" without
>>identifying a title, author, publisher, etc.
>>
>>
>>I think what is also unclear to me is why user's should be able to or
>>able to avoid doing author/title/publisher/etc.?
>>
>>Either they want to specify a reference system (some of which will be
>>predefined with that sort of information) or not. If someone is going
>>outside a defined set, I don't understand the reluctance to force them
>>to provide some minimal information about it. (I may be mis-reading your
>>post completely  so please correct if I have run off into the weeds.)
>>
>>Not sure what the refWork (which I have renamed in the schema to be
>>osisWork  to be consistent with our other usage) gains you in addition
>>to <osisWork>bible.lxx</osisWork>
>>
>>I would just say: <work osisWork="bible.lxx">, etc. and end with
>>whatever (if any) other information you wanted to include.
>>
>>Could even have: <work osisWork="bible.lxx"/>, with osisWorkType (the
>>type of the attribute value) being one of our extensible attribute
>>lists. The value in osisText of osisWork should match one of those
>>values or with the "x=" extension.
>>
>>
>>I think we are getting a little closer!
>>
>>Patrick
>>

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