Re: place holder for note element

Lou Burnard <[email protected]> Mon, 8 May 2017 15:04:14 +0100
Newsgroups gmane.text.tei.general
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--------------B0298249D97298D836C6B3DD
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Assuming I've understood correctly what you're trying to achieve here, I=20
think you probably want <anchor>, not <ref>. <anchor> can appear=20
anywhere (almost) since it's a milestonelike chappy. You can use its n=20
attribute to hold the siglum of your note, and you can give it an=20
xml:id. Then place it at the point of attachment for the <note> you're=20
moving.

On 08/05/17 14:47, Martin Mueller wrote:
> Is there an element that you can use as a place holder for <note> and t=
hat will be valid wherever <note> is valid?
>
> I ask because in a linguistically annotated version of the TCP texts I =
am moving <note> elements from their current inline position to special <=
div> elements at the end of each text. There are several reasons for doin=
g this: notes are a subgenre with distinct properties of their own, they =
have a lot of abbreviations and stuff in other languages. Moreover, they =
have five times as many transcription errors. So there are good practical=
 reasons for making it easier to identify and extract them for various pu=
rposes. For display purposes, you can always call them up from anywhere.
>
> Some notes have sigla, many do not.  But if you move them you need to m=
ark the place from which you move them, and the marker element will eithe=
r be empty or contain a letter, number, or other symbol. From a semantic =
perspective, <ref> would be an obvious choice, but its content model is m=
uch more restricted than that of note. Notes can appear as children of <d=
iv> and between <l> or <p> elements.  They often appear in those location=
s in  TCP texts.
>
> I have thought of various kludges. You can wrap <ref> in <ab> . If the =
note has no siglum and the transcriber put it between <l> or <p> elements=
 you can cheat and make it a child of the next or previous element on the=
 assumption that your decision may be as defensible as the transcriber=E2=
=80=99s.  You could also use <note> as a place holder. So you could have =
<note type=3D=E2=80=9Dref=E2=80=9D> as a pointer to the real note. None o=
f these strikes me as a very desirable solution.
>
> It may be that often the transcribers did the wrong thing. Given a sequ=
ence of <l>  or <p> elements, a <note> between elements may not make much=
 sense: which element does the note target?  On the other hand,  a note a=
ttached to a stanza (<lg>) makes perfect sense.  You can have <note> as t=
he last child of <lg>, but you can=E2=80=99t have <ref>*</ref> as a place=
 holder.
>
> Am I missing something obvious here, or is this an odd gap in the eleme=
nt toolkit?
>
>
>


--------------B0298249D97298D836C6B3DD
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Ty=
pe">
  </head>
  <body bgcolor=3D"#CCCCCC" text=3D"#000000">
    <p><font size=3D"+1"><font face=3D"Courier New, Courier, monospace">A=
ssuming
          I've understood correctly what you're trying to achieve here,
          I think you probably want &lt;anchor&gt;, not &lt;ref&gt;.
          &lt;anchor&gt; can appear anywhere (almost) since it's a
          milestonelike chappy. You can use its n attribute to hold the
          siglum of your note, and you can give it an xml:id. Then place
          it at the point of attachment for the &lt;note&gt; you're
          moving.=C2=A0</font></font></p>
    <div class=3D"moz-cite-prefix">On 08/05/17 14:47, Martin Mueller
      wrote:<br>
    </div>
    <blockquote
      cite=3D"mid:[email protected]"
      type=3D"cite">
      <pre wrap=3D"">Is there an element that you can use as a place hold=
er for &lt;note&gt; and that will be valid wherever &lt;note&gt; is valid=
?

I ask because in a linguistically annotated version of the TCP texts I am=
 moving &lt;note&gt; elements from their current inline position to speci=
al &lt;div&gt; elements at the end of each text. There are several reason=
s for doing this: notes are a subgenre with distinct properties of their =
own, they have a lot of abbreviations and stuff in other languages. Moreo=
ver, they have five times as many transcription errors. So there are good=
 practical reasons for making it easier to identify and extract them for =
various purposes. For display purposes, you can always call them up from =
anywhere.

Some notes have sigla, many do not.  But if you move them you need to mar=
k the place from which you move them, and the marker element will either =
be empty or contain a letter, number, or other symbol. From a semantic pe=
rspective, &lt;ref&gt; would be an obvious choice, but its content model =
is much more restricted than that of note. Notes can appear as children o=
f &lt;div&gt; and between &lt;l&gt; or &lt;p&gt; elements.  They often ap=
pear in those locations in  TCP texts.

I have thought of various kludges. You can wrap &lt;ref&gt; in &lt;ab&gt;=
 . If the note has no siglum and the transcriber put it between &lt;l&gt;=
 or &lt;p&gt; elements you can cheat and make it a child of the next or p=
revious element on the assumption that your decision may be as defensible=
 as the transcriber=E2=80=99s.  You could also use &lt;note&gt; as a plac=
e holder. So you could have &lt;note type=3D=E2=80=9Dref=E2=80=9D&gt; as =
a pointer to the real note. None of these strikes me as a very desirable =
solution.

It may be that often the transcribers did the wrong thing. Given a sequen=
ce of &lt;l&gt;  or &lt;p&gt; elements, a &lt;note&gt; between elements m=
ay not make much sense: which element does the note target?  On the other=
 hand,  a note attached to a stanza (&lt;lg&gt;) makes perfect sense.  Yo=
u can have &lt;note&gt; as the last child of &lt;lg&gt;, but you can=E2=80=
=99t have &lt;ref&gt;*&lt;/ref&gt; as a place holder.

Am I missing something obvious here, or is this an odd gap in the element=
 toolkit?



</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------B0298249D97298D836C6B3DD--