<pron> and phonemic/phonetic

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

<pron> and phonemic/phonetic

Martin Holmes
Hi all,

It's very common in born-digital dictionaries to distinguish between
different levels of transcription; for example, you might have phonemic
vs phonetic, and even multiple levels of phonetic transcription.

The natural way to do this would seem to be:

<form>
   <pron type="phonemic">....</pron>
   <pron type="phonetic">....</pron>
</form>

but of course @type is not available on <pron>. The only alternative I
can see is to use @notation, but that seems like a slightly off-label
use to me. How have other people handled this? Do you think it's worth
raising a feature request to add <pron> to att.typed, or are there
better alternatives?

Cheers,
Martin

--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: <pron> and phonemic/phonetic

Birnbaum, David J
Dear TEI-L (cc Martin),

I suggested many years ago, when I was a member of Council at the time that P5 was being developed, that @type be made globally available on all elements because 1) it strikes a reasonable balance between flexible and constrained, and 2) uses for it on different elements in ways that could not be foreseen by Council were likely to arise, and anticipating those uses and allowing for them in advance by making @type global had implementation and management advantages over responding to them one by one, with inevitable delay. My suggestion went nowhere at the time, but insofar as Martin's case, below, is one such unanticipated need, it provides an opportunity for me to ask again: would Council be willing not only to consider adding <pron> to att.typed, as Martin proposes, but, more generally, to reconsider the advantages and disadvantages of making @type a global attribute?

Sincerely,

David (Birnbaum)


On 8/5/20, 10:59 AM, "TEI (Text Encoding Initiative) public discussion list on behalf of Martin Holmes" <[hidden email] on behalf of [hidden email]> wrote:

    Hi all,
   
    It's very common in born-digital dictionaries to distinguish between
    different levels of transcription; for example, you might have phonemic
    vs phonetic, and even multiple levels of phonetic transcription.
   
    The natural way to do this would seem to be:
   
    <form>
       <pron type="phonemic">....</pron>
       <pron type="phonetic">....</pron>
    </form>
   
    but of course @type is not available on <pron>. The only alternative I
    can see is to use @notation, but that seems like a slightly off-label
    use to me. How have other people handled this? Do you think it's worth
    raising a feature request to add <pron> to att.typed, or are there
    better alternatives?
   
    Cheers,
    Martin
   
    --
    -------------------------------------
    Humanities Computing and Media Centre
    University of Victoria
    [hidden email]
   

Reply | Threaded
Open this post in threaded view
|

Re: <pron> and phonemic/phonetic

Jack Bowers
In reply to this post by Martin Holmes
Hi Martin!

I've had to add this to my ODD's for several different projects (though for slightly different specific uses), so I think this is indeed a perfect argument for adding <pron> to att.typed.

@notation isn't a good fit since you could be using IPA characters (the prototypical value of @notation) for both phonemic and phonetic form content.

I'll support the cause if you propose the change!

Best
Jack

On Wed, Aug 5, 2020 at 4:59 PM Martin Holmes <[hidden email]> wrote:
Hi all,

It's very common in born-digital dictionaries to distinguish between
different levels of transcription; for example, you might have phonemic
vs phonetic, and even multiple levels of phonetic transcription.

The natural way to do this would seem to be:

<form>
   <pron type="phonemic">....</pron>
   <pron type="phonetic">....</pron>
</form>

but of course @type is not available on <pron>. The only alternative I
can see is to use @notation, but that seems like a slightly off-label
use to me. How have other people handled this? Do you think it's worth
raising a feature request to add <pron> to att.typed, or are there
better alternatives?

Cheers,
Martin

--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: <pron> and phonemic/phonetic

Martin Holmes
Thanks David and Jack.

I think there is a perhaps justifiable instinctive resistance to any
proposal for a global attribute. Anything added to att.typed should
according to tradition be repeatable and categorizable, and since this
is clearly true of <pron>, I think it would be a straightforward feature
request.* Many TEI elements of course are not repeatable and/or
categorizable, which is the basis for not making att.typed a member of
att.global.

If no-one comes up with a good alternative in the next little while,
I'll raise a feature request.

Cheers,
Martin

* That's assuming the feature request doesn't get expanded into a vague
examination of a whole class of apparently similar elements, and then
languish for years because one or two of those elements are problematic,
which happens a bit too often. :-)


On 2020-08-05 8:12 a.m., Jack Bowers wrote:

> Hi Martin!
>
> I've had to add this to my ODD's for several different projects (though
> for slightly different specific uses), so I think this is indeed a
> perfect argument for adding <pron> to att.typed.
>
> @notation isn't a good fit since you could be using IPA characters (the
> prototypical value of @notation) for both phonemic and phonetic form
> content.
>
> I'll support the cause if you propose the change!
>
> Best
> Jack
>
> On Wed, Aug 5, 2020 at 4:59 PM Martin Holmes <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi all,
>
>     It's very common in born-digital dictionaries to distinguish between
>     different levels of transcription; for example, you might have phonemic
>     vs phonetic, and even multiple levels of phonetic transcription.
>
>     The natural way to do this would seem to be:
>
>     <form>
>         <pron type="phonemic">....</pron>
>         <pron type="phonetic">....</pron>
>     </form>
>
>     but of course @type is not available on <pron>. The only alternative I
>     can see is to use @notation, but that seems like a slightly off-label
>     use to me. How have other people handled this? Do you think it's worth
>     raising a feature request to add <pron> to att.typed, or are there
>     better alternatives?
>
>     Cheers,
>     Martin
>
>     --
>     -------------------------------------
>     Humanities Computing and Media Centre
>     University of Victoria
>     [hidden email] <mailto:[hidden email]>
>

--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: <pron> and phonemic/phonetic

Paul Schaffner
I think my first question(s) would be about its applicability to the
commonest situation in which alternative pronunciations are listed
in many dictionaries, born-digital or in print,
viz., when different dialects pronounce the word differently. On
the one hand, could your use case be handled by nesting <form>s?
On the other, could the existence of @type on pron allow one to
avoid nesting forms?

I.e., are there any real differences between

<form>
 <orth>nought</orth>
 <form>
  <usg type="geo">Brit.</usg>
  <pron notation="ipa">nɔːt</orth>
 </form>
 <form>
  <usg type="geo">US</usg>
  <pron notation="ipa">nɔt</pron>
 </form>
 <form>
  <usg type="geo">US</usg>
  <pron notation="ipa">nɑt</pron>
 </form>
</form>

and

<form>
 <orth>nought</orth>
 <pron type="British" notation="ipa">nɔːt</orth>
 <pron type="American" notation="ipa">nɔt</pron>
 <pron type="American" notation="ipa">nɑt</pron>
</form>

pfs


On Wed, Aug 5, 2020, at 11:40, Martin Holmes wrote:

> Thanks David and Jack.
>
> I think there is a perhaps justifiable instinctive resistance to any
> proposal for a global attribute. Anything added to att.typed should
> according to tradition be repeatable and categorizable, and since this
> is clearly true of <pron>, I think it would be a straightforward feature
> request.* Many TEI elements of course are not repeatable and/or
> categorizable, which is the basis for not making att.typed a member of
> att.global.
>
> If no-one comes up with a good alternative in the next little while,
> I'll raise a feature request.
>
> Cheers,
> Martin
>
> * That's assuming the feature request doesn't get expanded into a vague
> examination of a whole class of apparently similar elements, and then
> languish for years because one or two of those elements are problematic,
> which happens a bit too often. :-)
>
>
> On 2020-08-05 8:12 a.m., Jack Bowers wrote:
> > Hi Martin!
> >
> > I've had to add this to my ODD's for several different projects (though
> > for slightly different specific uses), so I think this is indeed a
> > perfect argument for adding <pron> to att.typed.
> >
> > @notation isn't a good fit since you could be using IPA characters (the
> > prototypical value of @notation) for both phonemic and phonetic form
> > content.
> >
> > I'll support the cause if you propose the change!
> >
> > Best
> > Jack
> >
> > On Wed, Aug 5, 2020 at 4:59 PM Martin Holmes <[hidden email]
> > <mailto:[hidden email]>> wrote:
> >
> >     Hi all,
> >
> >     It's very common in born-digital dictionaries to distinguish between
> >     different levels of transcription; for example, you might have phonemic
> >     vs phonetic, and even multiple levels of phonetic transcription.
> >
> >     The natural way to do this would seem to be:
> >
> >     <form>
> >         <pron type="phonemic">....</pron>
> >         <pron type="phonetic">....</pron>
> >     </form>
> >
> >     but of course @type is not available on <pron>. The only alternative I
> >     can see is to use @notation, but that seems like a slightly off-label
> >     use to me. How have other people handled this? Do you think it's worth
> >     raising a feature request to add <pron> to att.typed, or are there
> >     better alternatives?
> >
> >     Cheers,
> >     Martin
> >
> >     --
> >     -------------------------------------
> >     Humanities Computing and Media Centre
> >     University of Victoria
> >     [hidden email] <mailto:[hidden email]>
> >
>
> --
> -------------------------------------
> Humanities Computing and Media Centre
> University of Victoria
> [hidden email]
>

--
Paul Schaffner  Digital Content & Collections
University of Michigan Libraries
[hidden email] | http://www.umich.edu/~pfs/
Reply | Threaded
Open this post in threaded view
|

Re: <pron> and phonemic/phonetic

Martin Holmes
Hi Paul,

I think it would be up to the schema designer to decide whether variant
pronunciations amount to different <pron>s of the same <form> or
different <form>s in themselves. This case is specifically about the
level of transcription used for the same form. In other words the
pronunciation itself is not different in the case of a phonemic vs
phonetic (or broad versus narrow) transcription; it's just that the
latter is likely to include details such as allophonic variation.

I think if you wanted to simplify the example you cite, it could be done
by using pron/@xml:lang with appropriate region subtags for dialects
(en-GB-ENG etc.); you could then define those language/dialect details
elsewhere, with all the relevant geographical and usage information in a
single location.

Cheers,
Martin

On 2020-08-05 9:23 a.m., Paul Schaffner wrote:

> I think my first question(s) would be about its applicability to the
> commonest situation in which alternative pronunciations are listed
> in many dictionaries, born-digital or in print,
> viz., when different dialects pronounce the word differently. On
> the one hand, could your use case be handled by nesting <form>s?
> On the other, could the existence of @type on pron allow one to
> avoid nesting forms?
>
> I.e., are there any real differences between
>
> <form>
>   <orth>nought</orth>
>   <form>
>    <usg type="geo">Brit.</usg>
>    <pron notation="ipa">nɔːt</orth>
>   </form>
>   <form>
>    <usg type="geo">US</usg>
>    <pron notation="ipa">nɔt</pron>
>   </form>
>   <form>
>    <usg type="geo">US</usg>
>    <pron notation="ipa">nɑt</pron>
>   </form>
> </form>
>
> and
>
> <form>
>   <orth>nought</orth>
>   <pron type="British" notation="ipa">nɔːt</orth>
>   <pron type="American" notation="ipa">nɔt</pron>
>   <pron type="American" notation="ipa">nɑt</pron>
> </form>
>
> pfs
>
>
> On Wed, Aug 5, 2020, at 11:40, Martin Holmes wrote:
>> Thanks David and Jack.
>>
>> I think there is a perhaps justifiable instinctive resistance to any
>> proposal for a global attribute. Anything added to att.typed should
>> according to tradition be repeatable and categorizable, and since this
>> is clearly true of <pron>, I think it would be a straightforward feature
>> request.* Many TEI elements of course are not repeatable and/or
>> categorizable, which is the basis for not making att.typed a member of
>> att.global.
>>
>> If no-one comes up with a good alternative in the next little while,
>> I'll raise a feature request.
>>
>> Cheers,
>> Martin
>>
>> * That's assuming the feature request doesn't get expanded into a vague
>> examination of a whole class of apparently similar elements, and then
>> languish for years because one or two of those elements are problematic,
>> which happens a bit too often. :-)
>>
>>
>> On 2020-08-05 8:12 a.m., Jack Bowers wrote:
>>> Hi Martin!
>>>
>>> I've had to add this to my ODD's for several different projects (though
>>> for slightly different specific uses), so I think this is indeed a
>>> perfect argument for adding <pron> to att.typed.
>>>
>>> @notation isn't a good fit since you could be using IPA characters (the
>>> prototypical value of @notation) for both phonemic and phonetic form
>>> content.
>>>
>>> I'll support the cause if you propose the change!
>>>
>>> Best
>>> Jack
>>>
>>> On Wed, Aug 5, 2020 at 4:59 PM Martin Holmes <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>      Hi all,
>>>
>>>      It's very common in born-digital dictionaries to distinguish between
>>>      different levels of transcription; for example, you might have phonemic
>>>      vs phonetic, and even multiple levels of phonetic transcription.
>>>
>>>      The natural way to do this would seem to be:
>>>
>>>      <form>
>>>          <pron type="phonemic">....</pron>
>>>          <pron type="phonetic">....</pron>
>>>      </form>
>>>
>>>      but of course @type is not available on <pron>. The only alternative I
>>>      can see is to use @notation, but that seems like a slightly off-label
>>>      use to me. How have other people handled this? Do you think it's worth
>>>      raising a feature request to add <pron> to att.typed, or are there
>>>      better alternatives?
>>>
>>>      Cheers,
>>>      Martin
>>>
>>>      --
>>>      -------------------------------------
>>>      Humanities Computing and Media Centre
>>>      University of Victoria
>>>      [hidden email] <mailto:[hidden email]>
>>>
>>
>> --
>> -------------------------------------
>> Humanities Computing and Media Centre
>> University of Victoria
>> [hidden email]
>>
>

--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [External] <pron> and phonemic/phonetic

De Tienne, Andre
In reply to this post by Martin Holmes

This is not relevant regarding the proposed use of @type with <pron>, but this discussion gave me the occasion to notice that <pron> inherits attributes from att.datcat through att.lexicographic.

 

The att.datcat class provides attributes that “contain a PID (persistent identifier) that aligns the given element with the appropriate Data Category (or categories) in ISOcat.” It appears that ISOcat has been abandoned and replaced by a  Data Category Repository (DCR) called DatCatInfo (https://datcatinfo.net/), developed according to ISO 12620:2019 (http://www.isocat.org leads now only to a redirect to http://datcatinfo.net/). The latter refers to a concept database available at https://www.clarin.eu/ccr. The CLARIN Concept Registry (CCR) “initiated a Component MetaData Infrastructure (CMDI that provides a framework to describe and reuse metadata blueprints.” The CCR registry “contains the relevant concepts (based on the corresponding ISOcat data categories), such as those used by CMDI. The CCR has a less complex data model than ISOcat, and is also a closed registry.”

 

Searching the registry (https://concepts.clarin.eu/ccr/browser/) for the term “pronoun” yields 117 labeled concepts (including the relevant Stuttgart-Tübingen part-of-speech Tagset), each with a definition.

 

So there may be here an opportunity to revise the att.datcat class accordingly, so that certain ways of categorizing pronouns (and other such terms) correspond to currently retrievable standards? (Just raising the question: I am no linguist).

 

André

 

From: "TEI (Text Encoding Initiative) public discussion list" <[hidden email]> on behalf of Martin Holmes <[hidden email]>
Reply-To: Martin Holmes <[hidden email]>
Date: Wednesday, August 5, 2020 at 10:59 AM
To: "[hidden email]" <[hidden email]>
Subject: [External] <pron> and phonemic/phonetic

 

This message was sent from a non-IU address. Please exercise caution when clicking links or opening attachments from external sources.

-------

 

Hi all,

 

It's very common in born-digital dictionaries to distinguish between

different levels of transcription; for example, you might have phonemic

vs phonetic, and even multiple levels of phonetic transcription.

 

The natural way to do this would seem to be:

 

<form>

   <pron type="phonemic">....</pron>

   <pron type="phonetic">....</pron>

</form>

 

but of course @type is not available on <pron>. The only alternative I

can see is to use @notation, but that seems like a slightly off-label

use to me. How have other people handled this? Do you think it's worth

raising a feature request to add <pron> to att.typed, or are there

better alternatives?

 

Cheers,

Martin

 

--

-------------------------------------

Humanities Computing and Media Centre

University of Victoria

 

Reply | Threaded
Open this post in threaded view
|

Re: [External] <pron> and phonemic/phonetic

Martin Holmes
Hi André,

Our experience trying to use ISOcat with North American First Nations
languages has not been very positive. The structural organization of the
concepts in there is so firmly based on Indo-European languages that
it's really hard to make it work. We detailed some of our difficulties
in this paper:

<https://scholarspace.manoa.hawaii.edu/bitstream/10125/4604/8/czaykowska.pdf>

In addition, ISOcat itself has had a checkered history, and it actually
disappeared for a while, so although I'm glad to see
http://datcatinfo.net/ up and running, I also notice that TermWeb has an
expired certificate:

<https://datcatinfo.termweb.se/termweb/app>

which is not encouraging.

There's nothing in the TermWeb categories that I can find to represent
"phonemic" (although there is "phoneme"); there is a term "phonetic
form", but this is simply "Representation of the spoken string of a
form", which would seem to cover all levels of transcription. So using
this resource would not really help here.

Cheers,
Martin

On 2020-08-05 9:51 a.m., De Tienne, Andre wrote:

> This is not relevant regarding the proposed use of @type with <pron>,
> but this discussion gave me the occasion to notice that <pron> inherits
> attributes from att.datcat through att.lexicographic.
>
> The att.datcat class provides attributes that “contain a PID (persistent
> identifier) that aligns the given element with the appropriate Data
> Category (or categories) in ISOcat.” It appears that ISOcat has been
> abandoned and replaced by a  Data Category Repository (DCR) called
> DatCatInfo (https://datcatinfo.net/), developed according to ISO
> 12620:2019 (http://www.isocat.org leads now only to a redirect to
> http://datcatinfo.net/). The latter refers to a concept database
> available at https://www.clarin.eu/ccr. The CLARIN Concept Registry
> (CCR) “initiated a Component MetaData Infrastructure (CMDI
> <https://www.clarin.eu/glossary#CMDI> that provides a framework to
> describe and reuse metadata blueprints.” The CCR registry “contains the
> relevant concepts (based on the corresponding ISOcat data categories),
> such as those used by CMDI. The CCR has a less complex data model than
> ISOcat, and is also a closed registry.”
>
> Searching the registry (https://concepts.clarin.eu/ccr/browser/) for the
> term “pronoun” yields 117 labeled concepts (including the relevant
> Stuttgart-Tübingen part-of-speech Tagset), each with a definition.
>
> So there may be here an opportunity to revise the att.datcat class
> accordingly, so that certain ways of categorizing pronouns (and other
> such terms) correspond to currently retrievable standards? (Just raising
> the question: I am no linguist).
>
> André
>
> *From: *"TEI (Text Encoding Initiative) public discussion list"
> <[hidden email]> on behalf of Martin Holmes <[hidden email]>
> *Reply-To: *Martin Holmes <[hidden email]>
> *Date: *Wednesday, August 5, 2020 at 10:59 AM
> *To: *"[hidden email]" <[hidden email]>
> *Subject: *[External] <pron> and phonemic/phonetic
>
> This message was sent from a non-IU address. Please exercise caution
> when clicking links or opening attachments from external sources.
>
> -------
>
> Hi all,
>
> It's very common in born-digital dictionaries to distinguish between
>
> different levels of transcription; for example, you might have phonemic
>
> vs phonetic, and even multiple levels of phonetic transcription.
>
> The natural way to do this would seem to be:
>
> <form>
>
>     <pron type="phonemic">....</pron>
>
>     <pron type="phonetic">....</pron>
>
> </form>
>
> but of course @type is not available on <pron>. The only alternative I
>
> can see is to use @notation, but that seems like a slightly off-label
>
> use to me. How have other people handled this? Do you think it's worth
>
> raising a feature request to add <pron> to att.typed, or are there
>
> better alternatives?
>
> Cheers,
>
> Martin
>
> --
>
> -------------------------------------
>
> Humanities Computing and Media Centre
>
> University of Victoria
>
> [hidden email] <mailto:[hidden email]>
>

--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: <pron> and phonemic/phonetic

Roberto Rosselli Del Turco-2
In reply to this post by Jack Bowers
Hi Jack

Il 05.08.2020 17:12 Jack Bowers ha scritto:
> Hi Martin!
>
> I've had to add this to my ODD's for several different projects
> (though for slightly different specific uses), so I think this is
> indeed a perfect argument for adding <pron> to att.typed.

In general terms, I agree, it seems pretty straightforward to me.

> @notation isn't a good fit since you could be using IPA characters
> (the prototypical value of @notation) for both phonemic and phonetic
> form content.

To play the devil's advocate, you could have IPA_phonemic and
IPA_phonetic as values for @notation, though.

All best,

R
Reply | Threaded
Open this post in threaded view
|

Re: <pron> and phonemic/phonetic

Martin Holmes
Hi Roberto,

> To play the devil's advocate, you could have IPA_phonemic and
> IPA_phonetic as values for @notation, though.

Surely not. They're both the same notation (IPA); they're just different
levels of transcription. What's phonemic in one language may be
allophonic in another, so it's not as though there's a standard subset
of IPA for phonemic transcription and another for phonetic. I think that
would be attribute-abuse. :-)

Cheers,
Martin

On 2020-08-05 10:29 a.m., Roberto Rosselli Del Turco wrote:

> Hi Jack
>
> Il 05.08.2020 17:12 Jack Bowers ha scritto:
>> Hi Martin!
>>
>> I've had to add this to my ODD's for several different projects
>> (though for slightly different specific uses), so I think this is
>> indeed a perfect argument for adding <pron> to att.typed.
>
> In general terms, I agree, it seems pretty straightforward to me.
>
>> @notation isn't a good fit since you could be using IPA characters
>>  (the prototypical value of @notation) for both phonemic and
>> phonetic form content.
>
> To play the devil's advocate, you could have IPA_phonemic and
> IPA_phonetic as values for @notation, though.
>
> All best,
>
> R

--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: <pron> and phonemic/phonetic

Martin Holmes
Thanks for all the feedback! I've now added a feature request for this:

<https://github.com/TEIC/TEI/issues/2020>

Please add any comments you may have to the ticket.

Cheers,
Martin

On 2020-08-05 10:36 a.m., Martin Holmes wrote:

> Hi Roberto,
>
>> To play the devil's advocate, you could have IPA_phonemic and
>> IPA_phonetic as values for @notation, though.
>
> Surely not. They're both the same notation (IPA); they're just different
> levels of transcription. What's phonemic in one language may be
> allophonic in another, so it's not as though there's a standard subset
> of IPA for phonemic transcription and another for phonetic. I think that
> would be attribute-abuse. :-)
>
> Cheers,
> Martin
>
> On 2020-08-05 10:29 a.m., Roberto Rosselli Del Turco wrote:
>> Hi Jack
>>
>> Il 05.08.2020 17:12 Jack Bowers ha scritto:
>>> Hi Martin!
>>>
>>> I've had to add this to my ODD's for several different projects
>>> (though for slightly different specific uses), so I think this is
>>> indeed a perfect argument for adding <pron> to att.typed.
>>
>> In general terms, I agree, it seems pretty straightforward to me.
>>
>>> @notation isn't a good fit since you could be using IPA characters
>>>  (the prototypical value of @notation) for both phonemic and phonetic
>>> form content.
>>
>> To play the devil's advocate, you could have IPA_phonemic and
>> IPA_phonetic as values for @notation, though.
>>
>> All best,
>>
>> R
>
Reply | Threaded
Open this post in threaded view
|

Re: <pron> and phonemic/phonetic

Roberto Rosselli Del Turco-2
In reply to this post by Martin Holmes
Il 05.08.2020 19:36 Martin Holmes ha scritto:

> Hi Roberto,
>
>> To play the devil's advocate, you could have IPA_phonemic and
>> IPA_phonetic as values for @notation, though.
>
> Surely not. They're both the same notation (IPA); they're just
> different levels of transcription. What's phonemic in one language may
> be allophonic in another, so it's not as though there's a standard
> subset of IPA for phonemic transcription and another for phonetic. I
> think that would be attribute-abuse. :-)

I was sure you'd be going to tear that to pieces in a ms or so :)

I must say, though, the alternative being between customizing your
schema to add @type to <pron> and somewhat abusing @notation to make it
distinguish two different levels of transcription, well, I'd be somewhat
tempted by the latter.

Yeah, still playing the devil's advocate to reinforce the case for
adding @type to <pron>, think of the attributes! :)

Best,

R
Reply | Threaded
Open this post in threaded view
|

Re: <pron> and phonemic/phonetic

Martin Holmes
On 2020-08-05 10:43 a.m., Roberto Rosselli Del Turco wrote:

> Il 05.08.2020 19:36 Martin Holmes ha scritto:
>> Hi Roberto,
>>
>>> To play the devil's advocate, you could have IPA_phonemic and
>>> IPA_phonetic as values for @notation, though.
>>
>> Surely not. They're both the same notation (IPA); they're just
>> different levels of transcription. What's phonemic in one language may
>> be allophonic in another, so it's not as though there's a standard
>> subset of IPA for phonemic transcription and another for phonetic. I
>> think that would be attribute-abuse. :-)
>
> I was sure you'd be going to tear that to pieces in a ms or so :)
>
> I must say, though, the alternative being between customizing your
> schema to add @type to <pron> and somewhat abusing @notation to make it
> distinguish two different levels of transcription, well, I'd be somewhat
> tempted by the latter.

This:

<elementSpec ident="pron" module="dictionaries" mode="change">
   <classes mode="change">
     <memberOf mode="add" key="att.typed"/>
   </classes>
</elementSpec>

versus a lifetime of the shame and embarrassment associated with
attribute-abuse?

Cheers,
Martin

>
> Yeah, still playing the devil's advocate to reinforce the case for
> adding @type to <pron>, think of the attributes! :)
>
> Best,
>
> R

--
-------------------------------------
Humanities Computing and Media Centre
University of Victoria
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: <pron> and phonemic/phonetic

Martin Mueller
In reply to this post by Birnbaum, David J
I don’t' know the ins and outs of this, but what David says, especially about 2) rings true to me, having long been a fan of Brecht's lyrics in the Dreigroschenoper, especially,

Ja mach nur einen Plan
Sei nur ein grosses Licht
Und mach noch einen zweiten Plan
Gehn tun sie beide nicht.

The obvious objection to a universal @type attribute is that it invites chaos. To quote Elektra about her mother in Hofmannsthal's play: "Hier kommt ja alles zu allem." Bur perhaps it won't, and folks will make more sensible than silly decisions and adjust to each other.

MM





On 8/5/20, 9:08 AM, "TEI (Text Encoding Initiative) public discussion list on behalf of Birnbaum, David J" <[hidden email] on behalf of [hidden email]> wrote:

    Dear TEI-L (cc Martin),
   
    I suggested many years ago, when I was a member of Council at the time that P5 was being developed, that @type be made globally available on all elements because 1) it strikes a reasonable balance between flexible and constrained, and 2) uses for it on different elements in ways that could not be foreseen by Council were likely to arise, and anticipating those uses and allowing for them in advance by making @type global had implementation and management advantages over responding to them one by one, with inevitable delay. My suggestion went nowhere at the time, but insofar as Martin's case, below, is one such unanticipated need, it provides an opportunity for me to ask again: would Council be willing not only to consider adding <pron> to att.typed, as Martin proposes, but, more generally, to reconsider the advantages and disadvantages of making @type a global attribute?
   
    Sincerely,
   
    David (Birnbaum)
   
   
    On 8/5/20, 10:59 AM, "TEI (Text Encoding Initiative) public discussion list on behalf of Martin Holmes" <[hidden email] on behalf of [hidden email]> wrote:
   
        Hi all,
       
        It's very common in born-digital dictionaries to distinguish between
        different levels of transcription; for example, you might have phonemic
        vs phonetic, and even multiple levels of phonetic transcription.
       
        The natural way to do this would seem to be:
       
        <form>
           <pron type="phonemic">....</pron>
           <pron type="phonetic">....</pron>
        </form>
       
        but of course @type is not available on <pron>. The only alternative I
        can see is to use @notation, but that seems like a slightly off-label
        use to me. How have other people handled this? Do you think it's worth
        raising a feature request to add <pron> to att.typed, or are there
        better alternatives?
       
        Cheers,
        Martin
       
        --
        -------------------------------------
        Humanities Computing and Media Centre
        University of Victoria
        [hidden email]
       
   
   

Reply | Threaded
Open this post in threaded view
|

Re: [External] <pron> and phonemic/phonetic

Piotr Bański
In reply to this post by Martin Holmes
Hi all,

Some aspects of the datcat definition should be revised, to remove the
explicit reference to ISOCat and make it a generic attribute for
pointing at external reference data categories (not necessarily the
proprietary TermWeb). I'll see if I can raise a ticket to this effect.

Best wishes, and thanks, André, for bringing this up,

   Piotr

On 05/08/2020 19:15, Martin Holmes wrote:

> Hi André,
>
> Our experience trying to use ISOcat with North American First Nations
> languages has not been very positive. The structural organization of the
> concepts in there is so firmly based on Indo-European languages that
> it's really hard to make it work. We detailed some of our difficulties
> in this paper:
>
> <https://scholarspace.manoa.hawaii.edu/bitstream/10125/4604/8/czaykowska.pdf>
>
>
> In addition, ISOcat itself has had a checkered history, and it actually
> disappeared for a while, so although I'm glad to see
> http://datcatinfo.net/ up and running, I also notice that TermWeb has an
> expired certificate:
>
> <https://datcatinfo.termweb.se/termweb/app>
>
> which is not encouraging.
>
> There's nothing in the TermWeb categories that I can find to represent
> "phonemic" (although there is "phoneme"); there is a term "phonetic
> form", but this is simply "Representation of the spoken string of a
> form", which would seem to cover all levels of transcription. So using
> this resource would not really help here.
>
> Cheers,
> Martin
>
> On 2020-08-05 9:51 a.m., De Tienne, Andre wrote:
>> This is not relevant regarding the proposed use of @type with <pron>,
>> but this discussion gave me the occasion to notice that <pron>
>> inherits attributes from att.datcat through att.lexicographic.
>>
>> The att.datcat class provides attributes that “contain a PID
>> (persistent identifier) that aligns the given element with the
>> appropriate Data Category (or categories) in ISOcat.” It appears that
>> ISOcat has been abandoned and replaced by a  Data Category Repository
>> (DCR) called DatCatInfo (https://datcatinfo.net/), developed according
>> to ISO 12620:2019 (http://www.isocat.org leads now only to a redirect
>> to http://datcatinfo.net/). The latter refers to a concept database
>> available at https://www.clarin.eu/ccr. The CLARIN Concept Registry
>> (CCR) “initiated a Component MetaData Infrastructure (CMDI
>> <https://www.clarin.eu/glossary#CMDI> that provides a framework to
>> describe and reuse metadata blueprints.” The CCR registry “contains
>> the relevant concepts (based on the corresponding ISOcat data
>> categories), such as those used by CMDI. The CCR has a less complex
>> data model than ISOcat, and is also a closed registry.”
>>
>> Searching the registry (https://concepts.clarin.eu/ccr/browser/) for
>> the term “pronoun” yields 117 labeled concepts (including the relevant
>> Stuttgart-Tübingen part-of-speech Tagset), each with a definition.
>>
>> So there may be here an opportunity to revise the att.datcat class
>> accordingly, so that certain ways of categorizing pronouns (and other
>> such terms) correspond to currently retrievable standards? (Just
>> raising the question: I am no linguist).
>>
>> André
>>
>> *From: *"TEI (Text Encoding Initiative) public discussion list"
>> <[hidden email]> on behalf of Martin Holmes <[hidden email]>
>> *Reply-To: *Martin Holmes <[hidden email]>
>> *Date: *Wednesday, August 5, 2020 at 10:59 AM
>> *To: *"[hidden email]" <[hidden email]>
>> *Subject: *[External] <pron> and phonemic/phonetic
>>
>> This message was sent from a non-IU address. Please exercise caution
>> when clicking links or opening attachments from external sources.
>>
>> -------
>>
>> Hi all,
>>
>> It's very common in born-digital dictionaries to distinguish between
>>
>> different levels of transcription; for example, you might have phonemic
>>
>> vs phonetic, and even multiple levels of phonetic transcription.
>>
>> The natural way to do this would seem to be:
>>
>> <form>
>>
>>     <pron type="phonemic">....</pron>
>>
>>     <pron type="phonetic">....</pron>
>>
>> </form>
>>
>> but of course @type is not available on <pron>. The only alternative I
>>
>> can see is to use @notation, but that seems like a slightly off-label
>>
>> use to me. How have other people handled this? Do you think it's worth
>>
>> raising a feature request to add <pron> to att.typed, or are there
>>
>> better alternatives?
>>
>> Cheers,
>>
>> Martin
>>
>> --
>>
>> -------------------------------------
>>
>> Humanities Computing and Media Centre
>>
>> University of Victoria
>>
>> [hidden email] <mailto:[hidden email]>
>>
>