[osis-core] osisSubjects?

[Chris Little]

Todd & Patrick,

Conceptually, Todd's suggestion is good, but I don't know how it would 
work out in practice.  I would tend to favor our current implementation 
(with defined values in osisSubjects).  Reasons below:

1) I think the set of possible values is pretty low.  There aren't that 
many groups defining their own subject classification systems.

2) Symmetry with similar uses elsewhere in OSIS.  Usage of type on 
subject is very similar to usage of type on identifier (to my mind), 
which has values enumerated in osisIdentifier.

3) It requires reference to documents that don't exist and probably 
never will, in some cases because of copyright restrictions, in other 
cases because of unwieldily huge amounts of data.

4) The form of subject values is nothing like our osisIDs in form.  For 
examples, LCSH subjects include things like, "Bible--Dictionaries.", " 
Bible. English--Versions.", "Bible. N.T. Greek. 1871.", and "Bible. 
N.T.--Commentaries.".  I think, given that a full inventory of the LCSH 
would be essentially impossible to encode in a document, and would need 
almost constant updating, the form given by the LOC is probably best 
retained in each OSIS document that uses an LCSH itself.  In the absense 
of a document that actually defines mappings of osisID-like strings to 
actual subject values, implementers will invent their own attempted 
mappings and we'll void any possibility of interoperability.

5) If people need values other than what we provide they can suggest 
them for inclusion in the next revision and/or use the 
attributeExtension mechanism.

--Chris


Patrick Durusau wrote:

> Todd,
> 
> Todd Tillinghast wrote:
> 
>> Patrick,
>>
>> Where did the enumerated values for osisSubjects come from?
>>
> 
> List that I hacked together. Could move to documentation and use as you 
> suggest. Look for it in 1.9.4 (tomorrow morning).
> 
> Comments anyone?
> 
> Hope everyone is having a great day!
> 
> Patrick
> 
>> This list seems to have a narrow set of subject sets.
>>
>> This seems to be a limited set that would be better handled through the
>> use of a prefix like and osisID/osisRef.  Where the work is a document
>> that defines the set of subjects.  This is a scalable solution.
>>
>> I would suggest:
>> <osisText>   
>>     <header>
>>         <work osisWork="xyz">   
>>             ...
>>             <subject>atla:Subject</subject>
>>             ...
>>         </work>
>>         <work osisWork="atla">   
>>             ...
>>         </work>
>>     </header>
>>     ...
>> </osisText>
>>
>> This would also make the schema less brittle and allow for broader use.
>>
>> Todd
>>
>> _______________________________________________
>> osis-core mailing list
>> osis-core@bibletechnologieswg.org
>> http://www.bibletechnologieswg.org/mailman/listinfo/osis-core
>>
> 
>