Print

Print


Thanks Fabio!
As for a deep revision of the apparatus module, we all agree. But I really think we must not postpone fixing issues like this one and wait for a full revision of the module that will take a long time to come.
For the record, I've open a ticket on this topic:
https://listserv.brown.edu/archives/cgi-bin/wa?A1=ind1505&L=TEI-L#15
Anyone who wishes to contribute to this ticket is welcome.

Best wishes,
Marjorie

----- Mail original -----
De: "Burghart Marjorie" <[log in to unmask]>
À: "Fabio Ciotti" <[log in to unmask]>
Envoyé: Mercredi 20 Mai 2015 23:56:26
Objet: Re: Encoding divergent ending of a story (or: the <app> strikes back)

Thanks Fabio! 
As for a deep revision of the apparatus module, we all agree. But I really think we must not postpone fixing issues like this one and wait for a full revision of the module that will take a long time to come. 
For the record, I've open a ticket on this topic:
https://listserv.brown.edu/archives/cgi-bin/wa?A1=ind1505&L=TEI-L#15
Anyone who wishes to contribute to this ticket is welcome. 

Best wishes, 
Marjorie

----- Mail original -----
De: "Fabio Ciotti" <[log in to unmask]>
À: [log in to unmask]
Envoyé: Mercredi 20 Mai 2015 10:10:05
Objet: Re: Encoding divergent ending of a story (or: the <app> strikes back)

I think Marjorie request is quite reasonable. Stand-off is fascinating, but
when you come to applying it to real cases it is also painful, hard to
apply and control, and you end up to hide a lot of the representation in
the "would be" processing tool (otherwise we would had abandoned XML in the
end... to recall a recent thread).

I agree that IFF you can do the easy way (inline markup) then do it. Of
course I am not taking into account the tech problems to implement it in a
content model, but I find really wrong to give up reasonable changes in the
schema if a way to express it in XML is available (although difficult).

On the other hand I really do no like extending the set of tags when there
is no real need (Ockam principle): the <app> element stand for apparatus,
and apparatus does not change its very nature if it represents variation at
phrase or block or even container level. So I think that Marjorie should
raise asking the more natural and obvious modification, then the tech
council will discuss and eventually find a technical way to do it. I would
add that this request strengthen the awareness that the whole apparatus
module should go under a deep revision.

f

2015-05-20 9:39 GMT+02:00 Jens Østergaard Petersen <[log in to unmask]>:

> I am all for standoff markup, but I think one argument for parallel
> segmentation is that it is humanely comprehensible. Having alternatives to
> choose from represented as children of the <app> element is simply easy to
> grok. This must be in the background of this debate, but it is seldom
> expressed, perhaps because standoff markup is technically more advanced –
> and no one wants to be seen as being challenged in that respect.
>
> However, we can only juggle around with so many anchors and xml:ids in our
> heads at one time, so there needs to be a way to convert between inline
> markup and standoff markup. I have experimented with this, round tripping
> inline TEI (with text-critical markup) to standoff markup, and it can be
> made to work (skewed overlaps result in multiple representations of the
> text with overlaps).
>
> The use case Marjorie has for a block level <app>, where a number of block
> level elements alternate on their presence, is the simplest one. The real
> challenge is to encode a number of block level elements with different
> order – and not duplicating a lot of contents in the process. There is also
> a standoff solution for this, involving flattening the XML hierarchy,
> reordering it and then combining it again – a real Humpty-Dumpty if you
> will.
>
> I have not had time to play with this for quite a while. Some of the code
> is in <https://github.com/jensopetersen/ShakespeareStandoff>, some in <
> https://github.com/jensopetersen/mopane>, and some in my head – needless
> to say, this work is far from completed. Ah, yes: I should admit that the
> standoff markup I use is not TEI-based …. See also <
> https://stackoverflow.com/questions/21527660/transforming-sequence-of-elements-to-tree>
> and <
> https://stackoverflow.com/questions/20729593/transforming-tree-to-sequence-of-elements>
> for the help I got in coding the block level problem.
>
> Jens
>
> On 19 May 2015 at 23:54:19, Burghart Marjorie ([log in to unmask])
> wrote:
>
> Sebastian, what you describe is actually what happens in real life. Of
> course, a whole chapter, present in some manuscripts, can be omitted in
> others, so <app> should indeed be allowed to contain <div>s.
> Just making <app> to be a sibling of <p> would already be an improvement.
> But what would be really useful would be to allow <app> to contain several
> <p>s, just like a <div>. I'm guessing that containing <div>s is not the
> most important thing, if it helps with the content model (and your quills).
> In the case of the present / omitted chapter mentioned above, for instance,
> instead of this:
>
> <app>
> <lem>
> <div type="chapter">
> <p>...</p>
> <p>...</p>
> <p>...</p>
> <p>...</p>
> </div>
> </lem>
> <rdg wit="#C #D"/>
> </app>
>
> we could have a structure like this one:
>
> <div type="chapter">
> <app>
> <lem>
> <p>...</p>
> <p>...</p>
> <p>...</p>
> <p>...</p>
> </lem>
> <rdg/>
> </app>
> </div>
>
> That would be satisfying enough.
>
>
> ----- Mail original -----
> De: "Sebastian Rahtz" <[log in to unmask]>
> À: "Burghart Marjorie" <[log in to unmask]>
> Cc: [log in to unmask]
> Envoyé: Mardi 19 Mai 2015 23:23:35
> Objet: Re: Encoding divergent ending of a story (or: the <app> strikes
> back)
>
>
> > On 19 May 2015, at 22:06, Burghart Marjorie <[log in to unmask]>
> wrote:
> >
> >
> > I would argue that the point is not to loosen the TEI model, but to
> correct it.
> > As it is, the TEI model is assuming that variants do not occur at div or
> paragraph levels. This is just plain wrong.
>
>
> Hang on, now. You started asking for <app> to be a child of <div>, to
> allow for an entire paragraph
> being a variant. Now you’re saying that an entire <div> can be a variant;
> and I would assume you also
> would say that a <front> or a <titlePage> can be a variant too?
>
> Nothing wrong with this, but it raises horrendous problems in actually
> constructing TEI
> content models which support what you describe. My hair is doing its
> "quills upon the fretful porpentine”
> thing at the thought. You’d have to make <app> a member of model.global,
> so it could appear
> _anywhere_, and then give it a content model not unlike <floatingText>.
> And then you’d have
> to learn how to process it.
>
> If you want to compromise by saying that you just want <app> to be
> blocklike, i.e. be a sibling of <p>,
> my quills relax.
>
> Sebastian Rahtz
> Chief Data Architect, IT Services
>
>


-- 
Fabio Ciotti
Dipartimento Studi Umanistici, Università di Roma Tor Vergata
Presidente Associazione Informatica Umanistica Cultura Digitale