[osis-core] RE: Work Issue

Patrick Durusau osis-core@bibletechnologieswg.org
Thu, 30 Jan 2003 18:51:59 -0500


--------------090203050901040401010906
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Todd,

An initial reply but will more to probably follow tomorrow.

Todd Tillinghast wrote:

><snip>
>  
>
>>>If you believe that the prefix for identifiers in osisIDs NEED NOT
>>>      
>>>
>be
>  
>
>>>related to the THIS <work> element then this discussion would take
>>>      
>>>
>on a
>  
>
>>>different flavor related to what those other <work> elements mean.
>>>      
>>>
>This
>  
>
>>>may be where we are on different pages.
>>>      
>>>
>>Yes.  I also think this is where we differ.  The <refSystem> in THIS
>>work element is ONLY to define the default reference system used in
>>osisID's in this work.  It does not state ANYTHING else, including,
>>    
>>
>but
>  
>
>>not limitted to:
>>
>>this work includes ALL of this reference system
>>this work DEFINES this reference system
>>this work has no references outside of this reference system
>>this work has no references to any other reference system
>>
>>
>>It is ONLY the default.
>>    
>>
>
>Patrick, is where you are as well?
>  
>
Yes.

>  
>
>>	Do you agree?  Or probably better... could you agree? :)
>>
>>		-Troy.
>>    
>>
>
>I can go along with Troy's assignment of meaning if we can resolve what
>the <work> element related to the non-default prefix used in an osisID
>would mean.  (For convience I am going to call it the SECOND <work>
>element.)
>  
>
How about the default prefix means the <work> element referenced in 
osisText? And the <work> element gets only one canonical reference 
system. Does not mean that it cannot have others but it has only one for 
resolution of osisIDs.

What have we lost with that solution? Now that I think I understand the 
problem, I see even less reason for doing it. If there really is such a 
separate system, won't that be handled by the software? Not to mention 
that the second <work> element creates unnecessary problems for osisRefs 
with no gain that I can see.

Now that I think I understand what you want, do you have some argument 
for why we should change a system that works for one that creates more 
problems than it solves?

Patrick


>Because the THIS <work> element provides the meta data related to the
>current document, the SECOND <work> element should not repeat those
>elements.  It would seem that the SECOND <work> element should only
>include a <refSystem> sub-element.  This works fine for osisIDs because
>it is obvious that the THIS <work> element provides the meta-data and
>that the <work> with the matching prefix/osisWork value provides the
>reference system.  
>  
>
>The trouble would be when creating a reference within the same document.
>A reference using the SECOND <work> element would point to ANY document,
>when in this case it would seem that it should point to any document
>with the matching meta-data in the THIS <work> element.
>
>Are we on a different page here again?  With your perspectives that a
>reference using the SECOND <work> element would be exactly what it is
>and have no relationship to the current document, even though the SECOND
><work> element was created for use with osisIDs.  Is this a case where
>document encoders should not be stupid and would be forced to encode
>things using the default reference system?
>
>Todd
>
>
>
>_______________________________________________
>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
pdurusau@emory.edu
Co-Editor, ISO Reference Model for Topic Maps



--------------090203050901040401010906
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body>
Todd, <br>
<br>
An initial reply but will more to probably follow tomorrow.<br>
<br>
Todd Tillinghast wrote:<br>
<blockquote type="cite"
 cite="mid000101c2c8b6$0d8ef170$8100a8c0@halogenlight">
  <pre wrap="">&lt;snip&gt;
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">If you believe that the prefix for identifiers in osisIDs NEED NOT
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->be
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">related to the THIS &lt;work&gt; element then this discussion would take
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->on a
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">different flavor related to what those other &lt;work&gt; elements mean.
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->This
  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">may be where we are on different pages.
      </pre>
    </blockquote>
    <pre wrap="">Yes.  I also think this is where we differ.  The &lt;refSystem&gt; in THIS
work element is ONLY to define the default reference system used in
osisID's in this work.  It does not state ANYTHING else, including,
    </pre>
  </blockquote>
  <pre wrap=""><!---->but
  </pre>
  <blockquote type="cite">
    <pre wrap="">not limitted to:

this work includes ALL of this reference system
this work DEFINES this reference system
this work has no references outside of this reference system
this work has no references to any other reference system


It is ONLY the default.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Patrick, is where you are as well?
  </pre>
</blockquote>
Yes.<br>
<blockquote type="cite"
 cite="mid000101c2c8b6$0d8ef170$8100a8c0@halogenlight">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">	Do you agree?  Or probably better... could you agree? :)

		-Troy.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I can go along with Troy's assignment of meaning if we can resolve what
the &lt;work&gt; element related to the non-default prefix used in an osisID
would mean.  (For convience I am going to call it the SECOND &lt;work&gt;
element.)
  </pre>
</blockquote>
How about the default prefix means the &lt;work&gt; element referenced in
osisText? And the &lt;work&gt; element gets only one canonical reference
system. Does not mean that it cannot have others but it has only one for
resolution of osisIDs. <br>
<br>
What have we lost with that solution? Now that I think I understand the problem,
I see even less reason for doing it. If there really is such a separate system,
won't that be handled by the software? Not to mention that the second &lt;work&gt;
element creates unnecessary problems for osisRefs with no gain that I can
see. <br>
<br>
Now that I think I understand what you want, do you have some argument for
why we should change a system that works for one that creates more problems
than it solves?<br>
<br>
Patrick<br>
<br>
<br>
<blockquote type="cite"
 cite="mid000101c2c8b6$0d8ef170$8100a8c0@halogenlight">
  <pre wrap="">
Because the THIS &lt;work&gt; element provides the meta data related to the
current document, the SECOND &lt;work&gt; element should not repeat those
elements.  It would seem that the SECOND &lt;work&gt; element should only
include a &lt;refSystem&gt; sub-element.  This works fine for osisIDs because
it is obvious that the THIS &lt;work&gt; element provides the meta-data and
that the &lt;work&gt; with the matching prefix/osisWork value provides the
reference system.  
  </pre>
</blockquote>
<blockquote type="cite"
 cite="mid000101c2c8b6$0d8ef170$8100a8c0@halogenlight">
  <pre wrap="">
The trouble would be when creating a reference within the same document.
A reference using the SECOND &lt;work&gt; element would point to ANY document,
when in this case it would seem that it should point to any document
with the matching meta-data in the THIS &lt;work&gt; element.

Are we on a different page here again?  With your perspectives that a
reference using the SECOND &lt;work&gt; element would be exactly what it is
and have no relationship to the current document, even though the SECOND
&lt;work&gt; element was created for use with osisIDs.  Is this a case where
document encoders should not be stupid and would be forced to encode
things using the default reference system?

Todd



_______________________________________________
osis-core mailing list
<a class="moz-txt-link-abbreviated" href="mailto:osis-core@bibletechnologieswg.org">osis-core@bibletechnologieswg.org</a>
<a class="moz-txt-link-freetext" href="http://www.bibletechnologieswg.org/mailman/listinfo/osis-core">http://www.bibletechnologieswg.org/mailman/listinfo/osis-core</a>
  </pre>
</blockquote>
<br>
<pre class="moz-signature" cols="$mailwrapcol">-- 
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
<a class="moz-txt-link-abbreviated" href="mailto:pdurusau@emory.edu">pdurusau@emory.edu</a>
Co-Editor, ISO Reference Model for Topic Maps
</pre>
<br>
</body>
</html>

--------------090203050901040401010906--