Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Problem with labeled lists #41

Closed
JessedeDoes opened this issue Jan 9, 2018 · 9 comments
Closed

Problem with labeled lists #41

JessedeDoes opened this issue Jan 9, 2018 · 9 comments
Assignees
@proycon @kosloot

Comments

@JessedeDoes
Copy link

JessedeDoes commented Jan 9, 2018 •
edited
Loading

I have some files which have labels preceding list items.

I have some difficult to encode this in a way that ucto and foliavalidator will accept, cf attached files and error messages.

Neither
<item>
<label>a</label>
<t> .... text </t>
</item>

nor
<item>
<label>a</label>
<part><t> .... text </t></part>
</item>

work for me (The last option is accepted by foliavalidator)

error.log
metPart.mini.xml.txt
zonderPart.mini.xml.txt
@kosloot
Copy link
Contributor

kosloot commented Jan 10, 2018

Ok, there is a wealth of problems here.
Most of them are NOT an ucto problem but FoLiA issues.

folialint more or less issues the same messages. But more clear, not as a stack trace:
metPart.xml isn't a problem too, but:

> folialint zonderPart.mini.xml
zonderPart.mini.xml failed: 
inconsistent text: node item(TEI.1.text.1.body.1.div1.1.p.3.list.1.item.1) has a mismatch for the text in set:default
the element text ='La reformation de l'instruction du Conseil, qui peut cependant agir selon qu'il est instruict.'
the deeper text ='1.'

foliavalidator in fact states the same, stripping the slack:

line 79: [InconsistentText] Text for ListItem, ID TEI.1.text.1.body.1.div1.1.p.3.list.1.item.1, class default, is inconsistent: 
expected (after normalization): '1.', 
got (after normalization): 'La reformation de l'instruction du Conseil, qui peut cependant agir selon qu'il est instruict.'

This is correct imho: the text of the structure element 'item' should be the composition of the texts from it's structure element children.

  • for zonderPart the items text is the french text, and embedded is the label with text "1."
  • for metPart the items text is empty at first, but it can be composed of the children 'label and 'part'
    leading to composed text of: 1. La reformation de l'instruction du Conseil, qui peut cependant agir selon qu'il est instruict.'

This might come as a surprise :)
It would be insightful tot move the node in zonderPart at it's canonical position:

<item xml:id="TEI.1.text.1.body.1.div1.1.p.3.list.1.item.1">
    <t class="default">La reformation de l'instruction du Conseil, qui peut cependant agir selon qu'il est instruict.</t>
      <label>
          <t class="default">1.</t>
          <lang class="nld"/>
      </label>   
       ....

So this all needs some thought about wat you want to express....

Then there is the ucto problem..
ucto tries to tokenize the text of the 'label', (1.) which works and creates a paragraph with one sentence.
But a paragraph, NOR a sentence may be attached to a label.
This might be an oversight in the properties of FoLiA.

But is also raises an interesting idea:
Would it be a nice extension to be able to specify in ucto to skip certain FoLiA nodes ?

@proycon
Copy link
Member

proycon commented Jan 10, 2018

Wait.. this is not at all that complex. FoLiA has a generic "n" attribute which is used for labels in ordering. This is especially useful for list items. Example from the FoLiA documentation:

<head><t>My grocery list</t></head>
<list xml:id="example.list.1">
  <item xml:id="example.list.1.item.1" n="A"><t>Apples</t></item>
  <item xml:id="example.list.1.item.2" n="B"><t>Pears</t></item>                                                                                                                                                                                         
</list>

There is no <label> element in FoLiA. The labels covered by n are not considered text content subject to linguistic annotation, but more stylistic, which is I think precisely what we want.

@proycon
Copy link
Member

proycon commented Jan 10, 2018

Correction: we do have a label element it seems!.... It's not in the documentation though, so that's bad. I'll see if I can figure out what happened.

@JessedeDoes
Copy link
Author

JessedeDoes commented Jan 10, 2018 •
edited
Loading

Thanks! I can probably use the n=... option to encode the labels in my current Nederlab batch.

I was looking for a translation for the corresponding TEI tag, and took label from the folia schema as a possible translation of the TEI tag for list labels. In TEI, label is an element and may contain some markup (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-label.html), so translation by n=... will not always work.

@kosloot
Copy link
Contributor

kosloot commented Jan 10, 2018 •
edited
Loading

Well, the Label tag is there, but seems only halfway implemented.
I think that allowing <p> and <s> nodes in a <label> would be enough to do the trick.

But still remember: it's text is part of the document text then!

@kosloot kosloot mentioned this issue Jan 15, 2018
Closed
@kosloot
Copy link
Contributor

kosloot commented Jan 15, 2018

To clarify a bit: @JessedeDoes using the n attribute can be handy. And although it's name might suggest otherwise, it may contain any kind of text (within the XML limits for attributes).
On the downside: the content of the n attribute is opaque to the libraries. It is not taken into account by ucto, text retrieving functions etc.

@kosloot
Copy link
Contributor

kosloot commented Apr 10, 2018

@proycon : so what is the status of label now?
do we want to allow <p> en <s> nodes (or any abstract structure) in them?
if yes ==> a new FoLiA issue would be handy
in no ==> close the issue

@proycon
Copy link
Member

proycon commented Apr 10, 2018

Issue still open indeed, haven't had time to document this properly yet (bit of a lower priority). s might make some far-fetched sense for a label, but p probably not.

@proycon
Copy link
Member

proycon commented Apr 10, 2018

Ah wait, this is indeed a FoLiA issue rather than an ucto one, new issue makes sense. Closing this one.

@proycon proycon closed this as completed Apr 10, 2018
@proycon proycon mentioned this issue Apr 10, 2018
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@proycon proycon

@kosloot kosloot

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@proycon @JessedeDoes @kosloot