<div dir="ltr">I just asked a similar question, I believe, e.g. how to count certain clauses. Perhaps we're on the same train of thought.<div><br></div><div>For instance, we're using the Peer Conflict Resolution task (https://pubs.asha.org/doi/full/10.1044/1058-0360%282007/022%29), and their main outcomes measures are (1) mean length of T-unit, (2) clausal density (based on number of independent, nominative, relative and adverbial clauses) and (3) overall subordinate clause use. It's really quite difficult to train raters to code each clause type within an already heavily coded sample (e.g. we're doing typical word-level codes, utterance-level codes as well as correct information unit [e] codes), so I didn't know if there was something in the %gra dependencies that we could extract to get this information without hand-coding? Perhaps this is a similar answer to what Monika is looking for?</div><div><br></div><div>Best,</div><div><br>Brie</div><div><br><br>On Thursday, May 9, 2019 at 8:11:13 AM UTC-4, Monika Bader wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr">Dear Brian, <div>thanks for responding so quickly! We are working with written texts produced by young foreign language learners and want to code both for clauses and T-units/C-units to get ratios such as clauses per T-unit (a measure for which scoping is not crucial). We are relatively new to CLAN and had a tutorial with Victoria Johansson from Lund University, where they used CLAN for a big project on language development. They used the following strategy to encode T-units and clauses: clauses were placed on separate chat lines, while T-units were separated using @EndTurn. Center-embedded clauses (which there are many of in Swedish) were repeated on a separate subordinate tier, named %ces. </div><div>After reading the CHAT/CLAN manuals, we realized that an alternative option would be to place T-units on separate chat lines, and use [^c] to code for clauses. We have been since grappling with the possible consequences of choosing one strategy over the other, so if you have some thoughts around this, we would be happy to get your advice. We want later to share the corpus with our students for further analyses (and further coding), so we are trying to think carefully about the different options.So far we are leaning towards the [^c] strategy. Though T-units have been used in the literature to measure development, we are also interested in conducting a more detailed analysis, and investigating what kind of clauses and structures are inside those T-units to better understand what our learners can do and which clauses and structures they rely on. We are also interested in investigating the extent to which they use what LGSWE calls syntactic nonclausal structures (which seem to be quite common in our data set). We have the impression that a lot of this information can be encoded by modifying [^c]. It seems to us that there might be issues related to scoping if one then wanted to limit the search to features related to subtypes of [^c] (for instance, number of errors/or certain types of errors in certain types of clauses, such as relative clauses). It is possible that as you suggest these are better handled by relying on the %gra line, though I think we would have to conduct an extensive manual error analysis if we wanted to get a relatively accurate %gra line. </div><div><br></div><div>Best,</div><div>Monika</div><div><br>onsdag 8. mai 2019 16.01.54 UTC+2 skrev macw følgende:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Dear Monika,<div> I am not familiar with work that calculates MLU based on clauses and I am not sure why one would want to use such a measure. The major point of MLU is to consider the extent to which speakers compose more complex sentences and the act of breaking up sentences into clauses would actually remove the thing that it is trying to measure. </div><div> As you say, this system of clause marking is definitely not going to work well for center embedding. You could get the scope of the embedded clause, but then the main clause would be broken up. But perhaps that is interesting in itself. </div><div> I am curious why you are using this type of analysis. What exactly are you interested in measuring. It seems to me that, if you have a relatively accurate %gra line for an utterance, then that could be more useful that hand-done clause marking.</div><div><br></div><div>--Brian MacWhinney<br><div><br><blockquote type="cite"><div>On May 8, 2019, at 7:48 AM, 'Monika Bader' via chibolts <<a rel="nofollow">chib...@googlegroups.com</a>> wrote:</div><br><div><div dir="ltr">Hi,<div>we are trying to decide on the best way to code for clauses. The manual suggests using a clause delimiter, and we quite like this option (especially the possibility of creating user defined codes). However, we are somewhat worried about the scoping of the symbol. We understand that for some analyses, such as MLU/MLT based on clauses, this is not a crucial issue, but we do believe that for some other analyses one would need the right scoping (if we are not mistaken). For instance, calculating words per error free clauses (or any other clause code one uses). In examples such as </div><div><br></div><div>The book [that you buyed yesterday] [^c err] has disappeared [^c] </div><div><br></div><div>[^c err] would scope over "the book" as well, which we wouldn't necessarily want to include. In some languages these kinds of nested/center-embedded clauses are more common than in other. The manual says that "it is not necessary to mark the scope", but is it possible? or is there any other way to deal with cases such as these?<br></div><div><br></div><div>We appreciate any suggestions!</div><div><br></div><div>Best,</div><div>Monika</div></div><div><br></div>
-- <br>
You received this message because you are subscribed to the Google Groups "chibolts" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a rel="nofollow">chib...@googlegroups.com</a>.<br>
To post to this group, send email to <a rel="nofollow">chib...@googlegroups.com</a>.<br>
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/chibolts/9212b6f1-ad4c-4183-b277-45711661af3c%40googlegroups.com?utm_medium=email&utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/d/msgid/chibolts/9212b6f1-ad4c-4183-b277-45711661af3c%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter';return true;" onclick="this.href='https://groups.google.com/d/msgid/chibolts/9212b6f1-ad4c-4183-b277-45711661af3c%40googlegroups.com?utm_medium\x3demail\x26utm_source\x3dfooter';return true;">https://groups.google.com/d/<wbr>msgid/chibolts/9212b6f1-ad4c-<wbr>4183-b277-45711661af3c%<wbr>40googlegroups.com</a>.<br>
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/d/optout';return true;" onclick="this.href='https://groups.google.com/d/optout';return true;">https://groups.google.com/d/<wbr>optout</a>.<br>
</div></blockquote></div><br></div></div></blockquote></div></div></blockquote></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups "chibolts" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:chibolts+unsubscribe@googlegroups.com">chibolts+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/chibolts/d1542bee-a6f0-4f04-a50f-92432825a751%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/chibolts/d1542bee-a6f0-4f04-a50f-92432825a751%40googlegroups.com</a>.<br />