[tei-council] FR 3106829 on <quote> and <floatingText>

Martin Holmes mholmes at uvic.ca
Sun Apr 17 20:07:32 EDT 2011 

Hi Martin,

We should include your libretto example, then. It seems a pretty good 
instance of a text which is not external, but has richer internal structure.

Cheers,
Martin

On 11-04-17 04:40 PM, Martin Mueller wrote:
> My point was that the examples suggest a narrower range for<floatingText>
> than the formal definition. That is true of "enclosure," "attachment" or
> "embedded story." Many users will pay more attention to the examples than
> to the definition. So if we want to suggest that "coming from the outside"
> is not a necessary condition of<floatingText>, there should be at least
> one example  of<floatingText>  that clearly does not come from the
> outside, emanates from somewhere else, or whatever other phrase has been
> used.
>
> To use Laurent's language, I'm quite happy with the notion that
> floatingText is the appropriate element for  "subtexts that whose internal
> structure not match that of the encompassing document," "raisins in the
> oatmeal" as Paul Schaffner calls it. But given that definition we
> shouldn't muddy the water with a list of examples all of which are
> "external" in one way or another. In order to make that point crystal
> clear I'd suggest one further revision of the paragraph and say something
> like:
>
> The<floatingText>  element is simply used whenever the richer content
> model it provides is required to support mark up of a text or part of a
> text which presented as a discrete inclusion within the text. Such an
> "inclusion" might consist of a text that is perceived as external to the
> document, such as a letter, enclosure, or attachment. But it might equally
> well
> be the text of a "musical number" that is clearly set off from its
> surrounding text in
> the libretto of an opera but is equally clearly not perceived as external
> to the document.
>
>
>
> On 4/17/11 4:50 PM, "Piotr Bański"<bansp at o2.pl>  wrote:
>
>> I also like Kevin's paragraph, and, Martin (Mueller) -- I'm not sure
>> about the point you were making about<floatingText>: in two messages,
>> you mentioned "emanating from somewhere" as being the necessary
>> condition for that element (<floatingText>), whereas it was supposed to
>> be such a condition for<quote>, *not* for<floatingText>. Either there
>> was a nuance in what you wrote that I failed to catch, in which case I
>> apologise for bringing this up, or in your perception of the proposed
>> change, the condition for<quote>  shifted to<floatingText>, and that
>> was possibly at least a partial reason why you weren't absolutely happy
>> with this passage.
>>
>> (?)
>>
>>   P.
>>
>>
>> On 17.04.2011 20:21, Martin Holmes wrote:
>>> I vote a hearty yes to Kevin's paragraph below.
>>>
>>> I really think that getting any deeper into the "meaning" of
>>> floatingText will take us further from consensus; there's endless scope
>>> for disagreement, and we'll never satisfy everyone's intuitive sense of
>>> what it ought to represent.
>>>
>>> Cheers,
>>> Martin
>>>
>>> On 11-04-17 09:21 AM, Kevin Hawkins wrote:
>>>> Perhaps we could compromise on this?
>>>>
>>>> It is important to distinguish the use of<floatingText>   and<quote>.
>>>> Whereas the semantics of<quote>   imply that its content emanates from
>>>> somewhere external to the current text,<floatingText>   does not imply
>>>> this. The<floatingText>   element is simply used whenever the richer
>>>> content model it provides is required to support mark up of a text or
>>>> part of a text which is presented as a discrete inclusion within the
>>>> text. Such an inclusion might resemble an enclosure or an attachment in
>>>> the source document or an embedded story within a framing narrative, or
>>>> it might simply appear as an explicit quotation. Hence the two elements
>>>> may be used in combination: a<floatingText>   may appear within a<quote>
>>>> (when a text wich rich internal structure is quoted at length), and
>>>> <floatingText>   may also include one or more<quote>   elements as part
>>>> of
>>>> its own structure, just like any text.
>>>>
>>>> On 4/17/2011 10:55 AM, Laurent Romary wrote:
>>>>> I tend to agree with this. floatingText are sub-texts whose internal
>>>>> structure does not match that of the encompassing document. Call it
>>>>> syntaxic or not, I think we need to reflect this specificity without
>>>>> trying to make too much meaning of it.
>>>>> .
>>>>> Le 17 avr. 2011 à 16:09, Martin Mueller a écrit :
>>>>>
>>>>>> I am not sure whether this language really resolves the issues. How
>>>>>> floatingText relates to quote is one issue. But the deeper issue may
>>>>>> be
>>>>>> when and whether to use floatingText in the first place. Is it a
>>>>>> necessary
>>>>>> condition for floatingText that it "emanates from somewhere external
>>>>>> to
>>>>>> the current text text" and what does "external" mean?
>>>>>>
>>>>>> Martin Holmes sidestepped the issue of "external" by saying that it
>>>>>> was a
>>>>>> purely syntactic matter. Paul Schaffner in private correspondence
>>>>>> talked
>>>>>> about "raisins in the oatmeal." Thus floatingText functions like the
>>>>>> skin
>>>>>> of a raisin. Use it whenever you come across a raisin-like thing in
>>>>>> your
>>>>>> text.
>>>>>>
>>>>>> Defining floatingText in such purely formal a manner suited me fine
>>>>>> because it solves a problem of encoding recurring patterns in
>>>>>> libretto-like texts, but I confessed to a "lingering sense" that
>>>>>> this was
>>>>>> not quite right. I was comforted by Kevin's reassurance that nobody
>>>>>> else
>>>>>> shared this lingering sense. But Lou seems to share it when he says
>>>>>> that
>>>>>> "I don't like the implication that we cleanly distinguish 'semantic'
>>>>>> and
>>>>>> 'syntactic' elements.
>>>>>>
>>>>>> Lou's revision postulates 'discrete inclusion' as a necessary
>>>>>> condition
>>>>>> and the cited examples confirm that floatingText is something that
>>>>>> comes
>>>>>> from the outside. If that is right, what do you do with textual
>>>>>> "raisins"
>>>>>> that are not like enclosures or attachments but have a "rich internal
>>>>>> structure" that is not easily modeled within existing element rules?
>>>>>>
>>>>>> Let me return for a moment to an exchange from last October where I
>>>>>> raised
>>>>>> the question how to encode something like the following, which is
>>>>>> very
>>>>>> common in comic opera texts of the 18th century
>>>>>>
>>>>>> (Dialogue, unmarked)
>>>>>> A : I love you
>>>>>> B: I love you too
>>>>>>
>>>>>>
>>>>>> Duet (with title and typographical changes to mark its special staus)
>>>>>> A: I will love you forever
>>>>>> B: I will cherish you forever
>>>>>> AB: We will love and cherish each other forever
>>>>>>
>>>>>>
>>>>>> (Dialogue, unmarked)
>>>>>> A: Let's get married
>>>>>> B: Tomorrow
>>>>>>
>>>>>> Here the dialogue is the "oatmeal" and the duet is the "raisin." I
>>>>>> suggested three possible encodings, all of which parse:
>>>>>>
>>>>>>
>>>>>> 1. Turning the dialogue and duet sections into distinct div children
>>>>>> to
>>>>>> get a fully tesselated structure
>>>>>> 2. Using floatingText to encode the duet
>>>>>> 3. Using<q type="duet">    with some combination of<sp>    and<lg>
>>>>>> and
>>>>>> possibly<label>
>>>>>>
>>>>>> Lou said that using q was tag abuse and that the duet wasn't really a
>>>>>> separate text. I agree with both of these judgments. Lou then made a
>>>>>> proposal for a "speechgroup" element, which has languished so far on
>>>>>> SourceForge.  It provides a particular solution for a particular
>>>>>> kind of
>>>>>> raisin, but it does not offer a general solution for the recurring
>>>>>> phenomenon of bits of text that that have a 'rich internal
>>>>>> structure' but
>>>>>> do not come from the outside.
>>>>>>
>>>>>> Putting the definitions of q and floatingText next to each other
>>>>>> highlights some aspects of that problem. What is the difference
>>>>>> between
>>>>>> floatingText, which "contains a single text of any kind, whether
>>>>>> unitary
>>>>>> or composite, which interrupts the text containing it at any point
>>>>>> and
>>>>>> after which the surrounding text resumes"  and q, which "contains
>>>>>> material
>>>>>> which is marked as (ostensibly) being somehow different than the
>>>>>> surrounding text for any one of a variety of reason including but not
>>>>>> limit to direct speech."
>>>>>>
>>>>>> Coming back to my musical numbers problem, you can model them as
>>>>>> either q
>>>>>> or floatingText in ways that quite accurately represent the
>>>>>> structure of
>>>>>> the particular "raisins." But neither feels quite right, and my
>>>>>> sense is
>>>>>> that there areas of textual articulation or "set-offness" that are
>>>>>> not
>>>>>> well served by the current elements and their rules.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4/16/11 8:13 PM, "Kevin
>>>>>> Hawkins"<kevin.s.hawkins at ultraslavonic.info>
>>>>>> wrote:
>>>>>>
>>>>>>> This is good, but I think "or appear within  an explicit quotation"
>>>>>>> should be "or simply appear as an explicit quotation".  I've posted
>>>>>>> my
>>>>>>> slightly revised version in the ticket in SF.
>>>>>>>
>>>>>>> I think if there are no further objections, this is ready for
>>>>>>> implementation!
>>>>>>>
>>>>>>> On 4/15/11 3:37 PM, Lou Burnard wrote:
>>>>>>>> I don't like the implication that we cleanly distinguish
>>>>>>>> "semantic" and
>>>>>>>> "syntactic" elements. All elements are both in some sense. So
>>>>>>>> here's my
>>>>>>>> revision...
>>>>>>>>
>>>>>>>>
>>>>>>>> The semantics of<quote>     imply that its content emanates from
>>>>>>>> somewhere
>>>>>>>> external to the current text. The<floatingText>     element, on the
>>>>>>>> other
>>>>>>>> hand, is used whenever the richer content model it provides is
>>>>>>>> required
>>>>>>>> to support mark up of a  document or part of a document which is
>>>>>>>> presented as a discrete inclusion within the text. Such an
>>>>>>>> inclusion
>>>>>>>> might resemble an enclosure or an attachment, or an embedded story
>>>>>>>> within a framing narrative, or appear within  an explicit
>>>>>>>> quotation.
>>>>>>>> Hence the two elements may be used in combination: a<floatingText>
>>>>>>>>    may
>>>>>>>> appear within a<quote>, and may also of course include a<quote>
>>>>>>>> as
>>>>>>>> part of its own structure.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 12/04/11 14:29, Kevin Hawkins wrote:
>>>>>>>>> I've done some further revisions, so this is the latest version
>>>>>>>>> of the
>>>>>>>>> proposal for how to handle feature request 3106829.
>>>>>>>>>
>>>>>>>>> ###
>>>>>>>>>
>>>>>>>>> Replace:
>>>>>>>>>
>>>>>>>>> The floatingText element should only be used for complete texts
>>>>>>>>> which
>>>>>>>>> form a part of the text being encoded. Where a character in one
>>>>>>>>> narrative quotes from some other text or narrative, fully or in
>>>>>>>>> part,
>>>>>>>>> the quote element discussed in 3.3.3 Quotation should be used
>>>>>>>>> instead.
>>>>>>>>>
>>>>>>>>> with:
>>>>>>>>>
>>>>>>>>> It is important to distinguish the use of<floatingText>
>>>>>>>>> and<quote>.
>>>>>>>>> <quote>      is a semantic element for a passage attributed to an
>>>>>>>>> external
>>>>>>>>> agent, whereas<floatingText>      is a syntactic element and is
>>>>>>>>> used to
>>>>>>>>> provide rich internal structure for a text or part of a text
>>>>>>>>> which is
>>>>>>>>> included within the main text, such as an enclosure or attachment
>>>>>>>>> or
>>>>>>>>> simply a story within a frame narrative.  These elements may be
>>>>>>>>> used in
>>>>>>>>> combination. In the case of an extended quotation,<floatingText>
>>>>>>>>>    may
>>>>>>>>> be
>>>>>>>>> used as a child of<quote>.  On the other hand, there may be cases
>>>>>>>>> where
>>>>>>>>> a<floatingText>      includes one or more<quote>      elements as
>>>>>>>>> part of its
>>>>>>>>> structure.
>>>>>>>>>
>>>>>>>>> If there are no further comments in the next week, I can add this
>>>>>>>>> as a
>>>>>>>>> comment on the ticket.
>> _______________________________________________
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>> PLEASE NOTE: postings to this list are publicly archived
>
>

More information about the tei-council mailing list