Print

Print


On 20/05/15 10:47, Pierazzo, Elena wrote:
> 2. add it to the spannable elements, so that you can have a
> @spanTo when you need it, i.e; in case of overlapping

Why add @spanTo when you already have @from and @to and they are 
encouraged to be used *almost* in this manner?  Seems like 
duplication to me.

-James

>
> Elena
>
> __
> Elena Pierazzo
> Visiting Senior Research Fellow
> King's College London
> Department of Digital Humanities
> King's College London
> 26-29 Drury Lane
> London
> WC2B 5RL
>
> Professor of Italian Studies and Digital Humanities
> Bureau F307
> Université Grenoble Alpes - GERCI
> BP 25 38040 Grenoble Cedex 9
> Tel. +33 4 76828032
>
>> On 20 May 2015, at 10:10, Fabio Ciotti
>> <[log in to unmask] <mailto:[log in to unmask]>> wrote:
>>
>> 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] <mailto:[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]
>>     <mailto:[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]
>>>     <mailto:[log in to unmask]>>
>>>     À: "Burghart Marjorie" <[log in to unmask]
>>>     <mailto:[log in to unmask]>>
>>>     Cc: [log in to unmask]
>>>     <mailto:[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]
>>>     <mailto:[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
>


-- 
Dr James Cummings, [log in to unmask]
Academic IT Services, University of Oxford