Recognizing OSIS identifiers: Re: [osis-core] declaring identifiers/subjects and types thereon

[Patrick Durusau]

Troy,

Troy A. Griffitts wrote:
> Sounds ok to me, but if Todd really uses:
> 
> <identifier type="fba">Bible.es.RVR.1960</identifier>
> 
> I would contend that no software would recognize this as the OSIS 
> identifier for this work.
> 
> He would also need a:
> 
> <identifier type="OSIS">Bible.es.RVR.1960</identifier>
> 
> 
Never meant to contend that any software would. Just an illustration of 
how to modify his proposal.

Hope you are having a great day!

Patrick



> 
>     -Troy.
> 
> 
> 
> 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
>>
> 
> _______________________________________________
> osis-core mailing list
> osis-core@bibletechnologieswg.org
> http://www.bibletechnologieswg.org/mailman/listinfo/osis-core
> 


-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
Patrick.Durusau@sbl-site.org
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model

Topic Maps: Human, not artificial, intelligence at work!