[osis-core] declaring identifiers/subjects and types thereon

[Chris Little]

Patrick,

This sounds good to me also.

I'm happy with more information (i.e. type values that identify works), 
just frightened by the idea that we were losing a set of standard values.

--Chris


Patrick Durusau wrote:
> Chris,
> 
> Chris Little wrote:
> 
>> Patrick,
>>
>> I don't know if I quite understand this.  I interpret that you're saying
>>
>> <identifier type="OSIS">Bible.NASB</identifier>
>>
>> is incorrect, but
>>
>> <identifier type="OSIS:">Bible.NASB</identifier>
>>
>> is correct.  I don't understand the purpose of this, as it just looks 
>> like a namespace without any actual reference.  Or is the idea that it 
>> references an abstract document that would never exist?
>>
> 
> Yes, that is what I said was the current case, along with noting that it 
> was ERROR on my part.
> 
> The goal was to allow people (who want to) to declare an identifier or 
> subject that refers to a work, so they can use it as a prefix later in 
> the document.
> 
> The various simple strings that were enumerated in the schema had that 
> function. That is: ISBN, ISSN, etc., could be used as prefixes to values 
> so the software has a chance to know what sort of identifier it is 
> dealing with.
> 
> The "type" attribute should allow that simple string to be entered 
> without the ":" that everyone seems to find so offensive. The content of 
> the identifier and subject elements should also not be required to have 
> the colon.
> 
> In the case of an identifier, the goal is:
> 
> <identifier type="ISBN">158516002-4</identifier>
> 
> Which gives the ISBN identifier for this work (the KJV version from ABS).
> 
> Same is true for subject:
> 
> <subject type="LCSH">Bible</subject
> 
> What I hear being voiced is that type="OSIS" is being used as the 
> programmatic identifier for this work.
> 
> Fine by me.
> 
> Note that since <subject> can occur any number of times, there is no 
> reason for it to be a list, hence it can have spaces in the content of 
> the element, although not in the type attribute.
> 
> Same is the case for identifier.
> 
> To answer Todd's concerns, using his example:
> 
> <osisText osisIDWork="rvr" ...>
>    <header>
>       <work osisWork="rvr">
>          ...
>          <identifier type="fba">Bible.es.RVR.1960</identifier>
>          ...
>       </work>
>       <work osisWork="fba">
>          <title>Forum of Bible Agencies Bible Translation
> Identifiers</title>
>          ...
>       </work>
>    </header>
> </osisText>
> 
> Note the change of the type attribute on identifier to match the 
> osisWork attribute on the separate work.
> 
> This allows us to specify additional information on the authority that 
> provided the name in question. Same would be true for subject.
> 
> Chris thinks we should return the list of simple values for both 
> identifier and subject. I have no real case against that, but do think 
> it would be better to have a stock set of work elements that are capable 
> of directly the user to more information on the source of the identifier 
> or subject.
> 
> Note that I would prefer to return the enumerated list along with a 
> joint to xs:string and not attribute extension, so that if someone wants 
> to use the work mechanism to add one we don't have, they can do so 
> without the "x-" prefix.
> 
> For SBL purposes, I am sure we will draft work elements for all the 
> enumerated types on both identifier and subject.
> 
> Now, assuming the following:
> 
> 1. I fix the osisGenRegex (no longer relevant to this discussion),
> 
> 2. Get a show of hands on type on identifier and subject being xs:string 
> and having enumerated types for the most common values, which can also 
> be represented as work elements,
> 
> Does that close this part of the final debate?
> 
> Hope everyone is at the start of a great week!
> 
> Patrick
>