Deprecate oVar and pVar, Revamp oRef and pRef

[TEITechnicalCouncil]

The TEI dictionary chapter comprises four element for referring back to forms in dictionary entries (oRef, oVar, pRef, pVar), whose respective usage has never corresponded to clear-cut scenarios, especially because of the lack of clear set of use cases and examples. This has lead to a low usage of these elements in most TEI based dictionary projects but also in the absence of best practices for all the concrete cases (examples, etymology) where marking forms and associating them to (real or virtual) entries would help formalising lexical content in a systematic way.

The main issue is that the difference between pRef and pVar (resp. oRef/oVar) does not match the logic of tagging form references in a dictionary entry:

• pRef (resp. oRef) is limited (empty content) to the case where the form is exactly the one on the same entry, which is rarely the case (e.g. when orthographic variants exist)
• pVar is only intended to be used when there is a variation (e.g. inflected form) but contrary to pRef, but with its non empty content, it is often tempting to use it to mark all types of forms

It has also been pointed out that there are also issues related to the unsatisfactory definition of @type and the absence of @notation.

Proposal: we suggest to drop oVar and pVar and extent both the scope and content model of pRef and oRef to offer a simple system for the annotation of forms (orthographic and phonetic) in dictionary entries, with a clear parallel to orth and pron in the description of forms.

The main changes would be:

• allow text in oRef and pRef; while keeping the possibility to leave them empty when necessary
• make them member of att.typed
• make them member of att.lexicographic to bring them in line with and enable full correspondence with linguistic/lexicographic usage of orth> and prone
• add @notation in pRef in order to bring it in line with pron (probably a good opportunity to make a class out of @notation); useful in cases where there are more than one notations being represented in pron
• from a semantic point of view, allow these elements to point to any dictionary entry not just the current entry’s head item (same dictionary or even other dictionaries in the case of the marking up of etymology)

Original comment by: @laurentromary

[TEITechnicalCouncil]

This issue was originally assigned to SF user: stefaniegehrke Current user is: stefaniegehrke

[TEITechnicalCouncil]

This looks like a good step forward -- deprecating the Var elements while giving the Ref ones more flexibility is a welcome suggestion.

I have a remark and a request, for now:

• Syd has already handled @notation in pVar (see ticket #523), so extending this to the modified pRef definitely calls out for a class.
• would you please elaborate on the last point, i.e., the long-distance references, possibly by adducing some use cases? the suggestion seems logical on the one hand, but it also implies that the "tilde rendering" gets pushed from the more-or-less central focus of these elements, to a very contextual side-effect. I'm not saying it's bad, but its effect is worth highlighting already at this stage.

Original comment by: @bansp

[TEITechnicalCouncil]

To answer Piotr on the last point, here's a possible example of what we have in ming for etymology. It describes a borrowing from English to Japanese. The idea is to mark-up forms (and pronunciations) by means of the revamped oRef/pRef so that one can point to another lexical resource. It may be the case that this resource doe snot exist (yet) or cannot be referenced. @corresp is thus optional of course. But the underlying semantic that etymon are for that would potentially deserve lexical description seems important to me.

         <entry xml:id="taxi" xml:lang="jpn">
            <form type="lemma">
               <orth type="transliterated" notation="romanji">takushī</orth>
               <orth notation="katakana">タクシー</orth>
               <pron notation="ipa">taku'shi:</pron>
               <gramGrp>
                  <pos>noun</pos>
               </gramGrp>
            </form>
            <sense>
               <cit type="translation">
                  <quote>taxi</quote>
               </cit>
            </sense>
            <etym type="borrowing">
               <lbl>source</lbl>
               <lang>English</lang>
               <cit type="etymon">
                  <oRef xml:lang="eng-US" corresp="http://en.wiktionary.org/wiki/taxi">taxi</oRef>
                  <pRef xml:lang="eng-US">'tæksi</pRef>
               </cit>
            </etym>
         </entry>

Original comment by: @laurentromary

[TEITechnicalCouncil]

Hi Laurent, thanks for this, I'll try to have a closer look by the end of the day. This appears to take the *Ref elements into the new century, but then, that's what they needed.

One remark for now: your @xml:lang is placed too high: on the <entry>, it also incorrectly applies to <sense> and <etym>.

Original comment by: @bansp

[TEITechnicalCouncil]

... and 'tæksi is linguistically strange, as well. I don't know if xml:lang (or rather the relevant RFC or BP) accepts sublabels for phonetic script, but if it does, one should be applied here, I think.

Original comment by: @bansp

[TEITechnicalCouncil]

• assigned_to: Stefanie Gehrke

Original comment by: @hcayless

[TEITechnicalCouncil]

Assigning to Stefanie. This looks like a fair amount of work, and I think will need some discussion here and/or on the Council list, and may need to be broken up into smaller chunks. [feature-requests:#544] would be invalidated if this is implemented, so I think they go together.

Original comment by: @hcayless

[stefaniegehrke]

seems like there are existing projects using <oVar>, see the attached sample I recently looked at :

`

Union of European Football Associations

  </form>`

[laurentromary]

Stefanie: your message could not be read. I see two not incompatible strategies: a) deprecate the unwanted elements over a decent period (2 years); b) inform/consult the community concerning a possible transition. I gather there is a small group of concerned users in any case.

[stefaniegehrke]

thank you for the hint, Laurent

so once again : seems like there are existing projects using <oVar>, see the attached sample I recently looked at :

<form type="full"><orth><oVar>U</oVar>nion of <oVar>E</oVar>uropean <oVar>F</oVar>ootball <oVar>A</oVar>ssociations</orth></form>

[laurentromary]

Trying to re-activate this. A first step could be to adapt oRef and pRef so that it bears the same content model as oVar and pVar, and add @notation to the two by the same token. We could indicate in the documentation of oVar and pVar as a remark that there is a presence to use oRef and pRef as main representation tool.

[lb42]

So, to summarize: the proposal is a) deprecate use of oVar and pVar, recommending that oRef or pRef be used in preference b) make the proposed list of values for @type a semi-closed one c) add Ref elements to the new att.notated class d) change content model of Ref to match that of corresponding *Var element, but with the option of being empty All of that seems eminently simple and do-able. The ticket is with @stefaniegehrke to implement at present, but I can do it later this week if she asks me nicely!

[laurentromary]

That would be great!

[hcayless]

@lb42: @stefaniegehrke says go right ahead.

[lb42]

Implemented as above. The @type valList for oRef is already open and pRef doesn't have one.

[martindholmes]

Reopening this because the deprecation period is now over and the build is failing because of oVars.

[martindholmes]

Syd will do this while I do the Stylesheets problem.

[martindholmes]

Took a quick look at this and there are a lot of examples in other specs that use oVar, specifically in <case>, <mood>, <per> and <tns>. pVar is still being recommended in the Dictionaries chapter.

It rather looks like deprecation was added, but the additional steps of removing examples and references were not done. I see that the original request was for a two-year deprecation period. I think it might be a good idea to extend the deprecation for another six months or a year, and make sure there's at least one release that has fully-implemented deprecation (no examples or references) before actually removing these elements.

[bansp]

We might even consider raising Martin's proposal to the status of a principle.

[sydb]

I’m in favor of @martindholmes ’s proposal, too. I expect to start tackling this today, but he is right, there is quite a bit of work to be done. Unless I hear objections, I will change the @validUntil to mid-summer rather than actually remove <oVar> & <pVar>.

[martindholmes]

Forgive me for jumping in, but I've added a two-month extension to the deprecation of oVar and pVar in commit 1476d8d so that the build will go ahead on Jenkins and we can see if other commits are OK. Feel free to revert or override when a decision is made about how to proceed.

[sydb]

Since I got no response from the question on TEI-LINGUISTICS, I went ahead and made the changes. Pending discussion there, we can change the one example I’m not sure of (in DI, an <egXML> that now has an <oRef> inside an <oRef>).

Pushed at 2df3800.

[bansp]

Thanks, Syd. I missed that message, but I'd hesitate about how to reply because oRef is one of the hot topics of the TEI-Lex0 group now, and I wasn't much involved in the initial suggestions. Anyway, it's great to see things moving, thanks!

[sydb]

As far as I know, this issue is being kept open only because I am not confident about the encoding of the example “take … < was quite ~n with him >” in section DIHW (in chapter 9, Dictionaries). If someone more learned than I could confirm that it is OK, or suggest an improvement, that would be good.

[bansp]

We're meeting this Monday (whole day), and I will make sure to put this on the agenda.

[martindholmes]

The temporary extension on the expiry of oVar and pVar which I implemented in March has now expired, and the build is broken again. Should I extend it further, or are you ready to remove those elements?

[laurentromary]

I would definitely support this but we should make sure that there is an explicit remarks on oRef and pRef that these element are taking up the semantics of their counterparts.

[sydb]

OK. My plan is to remove these 2 elements this afternoon. Gives us ~2 months to reverse course if we don't like it.

[sydb]

So <pVar> and <oVar> are now gone as of be2ca61. If Mr. Jenkins is happy, will close this ticket.