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.

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

revise class hierarchy considering paragraphs and sentences #42

Closed
kosloot opened this issue Dec 8, 2017 · 3 comments
Closed

revise class hierarchy considering paragraphs and sentences #42

kosloot opened this issue Dec 8, 2017 · 3 comments
Assignees
Labels
enhancement ready Implemented but not released yet
Milestone

Comments

@kosloot
Copy link
Collaborator

kosloot commented Dec 8, 2017

At the moment, the accepted data considering sentence and/or paragraph is a bit rigid and unclear

For example:
A Caption may contain a Sentence, but not a Paragraph.
But that means that it also may contain several Sentences.
But isn't that just a Paragraph?

An Entry may NOT contain Sentence or Paragraph, but it may contain a Term, which may contain both.

An Utterance may contain a Sentence, but not a Paragraph, which somehow makes sense, but it may contain a Quote too, which accepts both.

The ratio is unclear to me.

@kosloot kosloot changed the title revise class hierarchy considering paragaps and sentences revise class hierarchy considering paragraps and sentences Dec 8, 2017
@kosloot kosloot changed the title revise class hierarchy considering paragraps and sentences revise class hierarchy considering paragraphs and sentences Dec 8, 2017
@kosloot
Copy link
Collaborator Author

kosloot commented Dec 8, 2017

This is related to: LanguageMachines/ucto#40

@proycon proycon added this to the v2.0 milestone Oct 10, 2018
@proycon proycon added the to do staged to be worked on label Oct 10, 2018
proycon added a commit that referenced this issue Feb 13, 2019
@proycon
Copy link
Owner

proycon commented Feb 13, 2019

I made it a bit more flexible, but that comes at a risk too, something I don't want to allow but which we currently can't enforce yet is a pattern like (xpath): //p/somethingelse/p

@proycon proycon added ready Implemented but not released yet and removed to do staged to be worked on labels Feb 13, 2019
@kosloot
Copy link
Collaborator Author

kosloot commented Feb 13, 2019

Yeah. There are several 'fair use' or 'sensible' policies for FoLiA, but enforcing them can be troublesome.
I'm not sure if DTD's or XmlSchema can rule this.
Otherwise we could implement some run-time checks.
e.g checking whether a <p> is embedded directly or indirectly in another <p> is not that hard.
Maybe MOST tags cannot be 'recursive'. So maybe we could make a property that allows this for the few that can? <div> comes to mind. <part> maybe?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement ready Implemented but not released yet
Projects
None yet
Development

No branches or pull requests

2 participants