WARNING: elements to be removed from att.dimensions

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

WARNING: elements to be removed from att.dimensions

Syd Bauman-10
The TEI Technical Council plans to remove the elements listed below
from the att.dimensions class. This means that these elements would
lose the following attributes:

   atLeast=, atMost=, confidence=, extent=, max=, min=, precision=,
   quantity=, scope=, and unit=

These attributes (which are used for expressing a measurement or
statistical information about a set) should never have been on these
elements in the first place. Thus their presence is considered a
corrigible error, and their removal is scheduled to take place at the
next release (likely in Jan or Feb 2018) without a 2-year
"deprecation" period, during which use of these attributes on these
elements would cause a warning to occur.

The elements that will lose these attributes are:

  <affiliation>, <am>, <birth>, <climate>, <corr>, <date>, <death>,
  <education>, <event>, <expan>, <faith>, <floruit>, <geogName>,
  <langKnowledge>, <langKnown>, <location>, <name>, <nationality>,
  <occupation>, <org>, <orgName>, <origDate>, <origPlace>, <origin>,
  <persName>, <person>, <persona>,[1] <place>, <placeName>, <reg>,
  <relation>, <residence>, <sex>, <socecStatus>, <terrain>, and
  <time>.[2]

If anyone is actually using one of these attributes on one of these
elements, and its removal in future releases might be a hardship,
please let us know by posting here or to the issue
(https://github.com/TEIC/TEI/issues/299).

Thank you.

Notes
-----
[1] The <persona> element was not actually discussed in detail on the
    issue 299 discussion board, but its removal from the
    att.dimensions class seems entirely uncontroversial.

[2] While time is something measurable and quantifiable, the
    attributes in att.dimension and att.ranging are not appropriate
    for the <time> element because measurements of temporal
    dimensions are typically more complex than a simple quantity and
    unit pairing, and are thus handled by att.duration; furthermore a
    set of temporal measurements would not be reported in a single
    <time> element, but rather in a set of them.
Reply | Threaded
Open this post in threaded view
|

Re: WARNING: elements to be removed from att.dimensions

John T Young
On the Casebooks Project we use @precision loads on <time> and less
often but still often enough on <date>. It seems (to me) a succinct way
of saying 'this must have happened at around this time but not
necessarily at exactly this time'. What should we use instead - @cert?
That seems less satisfactory to me, because we aren't trying to say we
aren't sure that it was around that time, just that we aren't sure
exactly what 'around' means (which rules out @notBefore and @notAfter).

John


On 05/12/2017 14:29, Syd Bauman wrote:

> The TEI Technical Council plans to remove the elements listed below
> from the att.dimensions class. This means that these elements would
> lose the following attributes:
>
>     atLeast=, atMost=, confidence=, extent=, max=, min=, precision=,
>     quantity=, scope=, and unit=
>
> These attributes (which are used for expressing a measurement or
> statistical information about a set) should never have been on these
> elements in the first place. Thus their presence is considered a
> corrigible error, and their removal is scheduled to take place at the
> next release (likely in Jan or Feb 2018) without a 2-year
> "deprecation" period, during which use of these attributes on these
> elements would cause a warning to occur.
>
> The elements that will lose these attributes are:
>
>    <affiliation>, <am>, <birth>, <climate>, <corr>, <date>, <death>,
>    <education>, <event>, <expan>, <faith>, <floruit>, <geogName>,
>    <langKnowledge>, <langKnown>, <location>, <name>, <nationality>,
>    <occupation>, <org>, <orgName>, <origDate>, <origPlace>, <origin>,
>    <persName>, <person>, <persona>,[1] <place>, <placeName>, <reg>,
>    <relation>, <residence>, <sex>, <socecStatus>, <terrain>, and
>    <time>.[2]
>
> If anyone is actually using one of these attributes on one of these
> elements, and its removal in future releases might be a hardship,
> please let us know by posting here or to the issue
> (https://github.com/TEIC/TEI/issues/299).
>
> Thank you.
>
> Notes
> -----
> [1] The <persona> element was not actually discussed in detail on the
>      issue 299 discussion board, but its removal from the
>      att.dimensions class seems entirely uncontroversial.
>
> [2] While time is something measurable and quantifiable, the
>      attributes in att.dimension and att.ranging are not appropriate
>      for the <time> element because measurements of temporal
>      dimensions are typically more complex than a simple quantity and
>      unit pairing, and are thus handled by att.duration; furthermore a
>      set of temporal measurements would not be reported in a single
>      <time> element, but rather in a set of them.
Reply | Threaded
Open this post in threaded view
|

Re: WARNING: elements to be removed from att.dimensions

Martin Holmes
I've also used @precision on <date>. I'd also use @confidence if its
definition wasn't so closely tied to @min and @max; it would be nice to
be able to use the combination of @confidence, @notBefore and @notAfter
to specify a date range with less than 100% confidence.

Cheers,
Martin

On 2017-12-05 08:17 AM, John T Young wrote:

> On the Casebooks Project we use @precision loads on <time> and less
> often but still often enough on <date>. It seems (to me) a succinct way
> of saying 'this must have happened at around this time but not
> necessarily at exactly this time'. What should we use instead - @cert?
> That seems less satisfactory to me, because we aren't trying to say we
> aren't sure that it was around that time, just that we aren't sure
> exactly what 'around' means (which rules out @notBefore and @notAfter).
>
> John
>
>
> On 05/12/2017 14:29, Syd Bauman wrote:
>> The TEI Technical Council plans to remove the elements listed below
>> from the att.dimensions class. This means that these elements would
>> lose the following attributes:
>>
>>     atLeast=, atMost=, confidence=, extent=, max=, min=, precision=,
>>     quantity=, scope=, and unit=
>>
>> These attributes (which are used for expressing a measurement or
>> statistical information about a set) should never have been on these
>> elements in the first place. Thus their presence is considered a
>> corrigible error, and their removal is scheduled to take place at the
>> next release (likely in Jan or Feb 2018) without a 2-year
>> "deprecation" period, during which use of these attributes on these
>> elements would cause a warning to occur.
>>
>> The elements that will lose these attributes are:
>>
>>    <affiliation>, <am>, <birth>, <climate>, <corr>, <date>, <death>,
>>    <education>, <event>, <expan>, <faith>, <floruit>, <geogName>,
>>    <langKnowledge>, <langKnown>, <location>, <name>, <nationality>,
>>    <occupation>, <org>, <orgName>, <origDate>, <origPlace>, <origin>,
>>    <persName>, <person>, <persona>,[1] <place>, <placeName>, <reg>,
>>    <relation>, <residence>, <sex>, <socecStatus>, <terrain>, and
>>    <time>.[2]
>>
>> If anyone is actually using one of these attributes on one of these
>> elements, and its removal in future releases might be a hardship,
>> please let us know by posting here or to the issue
>> (https://github.com/TEIC/TEI/issues/299).
>>
>> Thank you.
>>
>> Notes
>> -----
>> [1] The <persona> element was not actually discussed in detail on the
>>      issue 299 discussion board, but its removal from the
>>      att.dimensions class seems entirely uncontroversial.
>>
>> [2] While time is something measurable and quantifiable, the
>>      attributes in att.dimension and att.ranging are not appropriate
>>      for the <time> element because measurements of temporal
>>      dimensions are typically more complex than a simple quantity and
>>      unit pairing, and are thus handled by att.duration; furthermore a
>>      set of temporal measurements would not be reported in a single
>>      <time> element, but rather in a set of them.
Reply | Threaded
Open this post in threaded view
|

Re: WARNING: elements to be removed from att.dimensions

Simona Stoyanova
Many EpiDoc projects use @precision on <origDate> exactly for cases such as the ones John talks about - a date is flagged as approximate, which is different from being uncertain.

There are even recommendations in the EpiDoc guidelines as to what values people might use for @precision, based on epigraphic conventions: value 'low' for an approximate date (often written "circa", "ca." or "c."); value 'medium' if a date range is specified (with @notBefore-custom and @notAfter-custom) whose start and end points are essentially arbitrary, such as a century or half-century for a palaeographical date, to indicate that the start and end-points are both notional.

On 5 December 2017 at 16:24, Martin Holmes <[hidden email]> wrote:
I've also used @precision on <date>. I'd also use @confidence if its definition wasn't so closely tied to @min and @max; it would be nice to be able to use the combination of @confidence, @notBefore and @notAfter to specify a date range with less than 100% confidence.

Cheers,
Martin


On 2017-12-05 08:17 AM, John T Young wrote:
On the Casebooks Project we use @precision loads on <time> and less often but still often enough on <date>. It seems (to me) a succinct way of saying 'this must have happened at around this time but not necessarily at exactly this time'. What should we use instead - @cert? That seems less satisfactory to me, because we aren't trying to say we aren't sure that it was around that time, just that we aren't sure exactly what 'around' means (which rules out @notBefore and @notAfter).

John


On 05/12/2017 14:29, Syd Bauman wrote:
The TEI Technical Council plans to remove the elements listed below
from the att.dimensions class. This means that these elements would
lose the following attributes:

    atLeast=, atMost=, confidence=, extent=, max=, min=, precision=,
    quantity=, scope=, and unit=

These attributes (which are used for expressing a measurement or
statistical information about a set) should never have been on these
elements in the first place. Thus their presence is considered a
corrigible error, and their removal is scheduled to take place at the
next release (likely in Jan or Feb 2018) without a 2-year
"deprecation" period, during which use of these attributes on these
elements would cause a warning to occur.

The elements that will lose these attributes are:

   <affiliation>, <am>, <birth>, <climate>, <corr>, <date>, <death>,
   <education>, <event>, <expan>, <faith>, <floruit>, <geogName>,
   <langKnowledge>, <langKnown>, <location>, <name>, <nationality>,
   <occupation>, <org>, <orgName>, <origDate>, <origPlace>, <origin>,
   <persName>, <person>, <persona>,[1] <place>, <placeName>, <reg>,
   <relation>, <residence>, <sex>, <socecStatus>, <terrain>, and
   <time>.[2]

If anyone is actually using one of these attributes on one of these
elements, and its removal in future releases might be a hardship,
please let us know by posting here or to the issue
(https://github.com/TEIC/TEI/issues/299).

Thank you.

Notes
-----
[1] The <persona> element was not actually discussed in detail on the
     issue 299 discussion board, but its removal from the
     att.dimensions class seems entirely uncontroversial.

[2] While time is something measurable and quantifiable, the
     attributes in att.dimension and att.ranging are not appropriate
     for the <time> element because measurements of temporal
     dimensions are typically more complex than a simple quantity and
     unit pairing, and are thus handled by att.duration; furthermore a
     set of temporal measurements would not be reported in a single
     <time> element, but rather in a set of them.



--
Simona Stoyanova
Research Fellow
COACS project

Institute of Classical Studies
University of London
Senate House
Malet Street
London WC1E 7HU

Email: [hidden email]
Tel: <a href="tel:+44+(0)20+7862+8724" target="_blank">+44 (0)20 7862 8724 
Reply | Threaded
Open this post in threaded view
|

Re: WARNING: elements to be removed from att.dimensions

Tom Elliott-3
It would, in my view, be helpful for the Council to offer suggestions of alternative tagging strategies for the use cases others have surfaced on this thread, and to do so well in advance of the mooted change. Thanks.

--
Tom Elliott, Ph.D.
Associate Director for Digital Programs and Senior Research Scholar
Institute for the Study of the Ancient World (NYU)

Humanities Commons: @paregorios

On Tue, Dec 5, 2017 at 10:35 AM, Simona Stoyanova <[hidden email]> wrote:
Many EpiDoc projects use @precision on <origDate> exactly for cases such as the ones John talks about - a date is flagged as approximate, which is different from being uncertain.

There are even recommendations in the EpiDoc guidelines as to what values people might use for @precision, based on epigraphic conventions: value 'low' for an approximate date (often written "circa", "ca." or "c."); value 'medium' if a date range is specified (with @notBefore-custom and @notAfter-custom) whose start and end points are essentially arbitrary, such as a century or half-century for a palaeographical date, to indicate that the start and end-points are both notional.

On 5 December 2017 at 16:24, Martin Holmes <[hidden email]> wrote:
I've also used @precision on <date>. I'd also use @confidence if its definition wasn't so closely tied to @min and @max; it would be nice to be able to use the combination of @confidence, @notBefore and @notAfter to specify a date range with less than 100% confidence.

Cheers,
Martin


On 2017-12-05 08:17 AM, John T Young wrote:
On the Casebooks Project we use @precision loads on <time> and less often but still often enough on <date>. It seems (to me) a succinct way of saying 'this must have happened at around this time but not necessarily at exactly this time'. What should we use instead - @cert? That seems less satisfactory to me, because we aren't trying to say we aren't sure that it was around that time, just that we aren't sure exactly what 'around' means (which rules out @notBefore and @notAfter).

John


On 05/12/2017 14:29, Syd Bauman wrote:
The TEI Technical Council plans to remove the elements listed below
from the att.dimensions class. This means that these elements would
lose the following attributes:

    atLeast=, atMost=, confidence=, extent=, max=, min=, precision=,
    quantity=, scope=, and unit=

These attributes (which are used for expressing a measurement or
statistical information about a set) should never have been on these
elements in the first place. Thus their presence is considered a
corrigible error, and their removal is scheduled to take place at the
next release (likely in Jan or Feb 2018) without a 2-year
"deprecation" period, during which use of these attributes on these
elements would cause a warning to occur.

The elements that will lose these attributes are:

   <affiliation>, <am>, <birth>, <climate>, <corr>, <date>, <death>,
   <education>, <event>, <expan>, <faith>, <floruit>, <geogName>,
   <langKnowledge>, <langKnown>, <location>, <name>, <nationality>,
   <occupation>, <org>, <orgName>, <origDate>, <origPlace>, <origin>,
   <persName>, <person>, <persona>,[1] <place>, <placeName>, <reg>,
   <relation>, <residence>, <sex>, <socecStatus>, <terrain>, and
   <time>.[2]

If anyone is actually using one of these attributes on one of these
elements, and its removal in future releases might be a hardship,
please let us know by posting here or to the issue
(https://github.com/TEIC/TEI/issues/299).

Thank you.

Notes
-----
[1] The <persona> element was not actually discussed in detail on the
     issue 299 discussion board, but its removal from the
     att.dimensions class seems entirely uncontroversial.

[2] While time is something measurable and quantifiable, the
     attributes in att.dimension and att.ranging are not appropriate
     for the <time> element because measurements of temporal
     dimensions are typically more complex than a simple quantity and
     unit pairing, and are thus handled by att.duration; furthermore a
     set of temporal measurements would not be reported in a single
     <time> element, but rather in a set of them.



--
Simona Stoyanova
Research Fellow
COACS project

Institute of Classical Studies
University of London
Senate House
Malet Street
London WC1E 7HU

Email: [hidden email]
Tel: <a href="tel:+44+(0)20+7862+8724" target="_blank">+44 (0)20 7862 8724 

Reply | Threaded
Open this post in threaded view
|

Re: WARNING: elements to be removed from att.dimensions

Lou Burnard-6

Or even maybe reconsider the wisdom of making this mooted change.


On 05/12/17 18:23, Thomas Elliott wrote:
It would, in my view, be helpful for the Council to offer suggestions of
alternative tagging strategies for the use cases others have surfaced on
this thread, and to do so well in advance of the mooted change. Thanks.


Reply | Threaded
Open this post in threaded view
|

Re: WARNING: elements to be removed from att.dimensions

Hugh Cayless-2
This request (https://github.com/TEIC/TEI/issues/299) actually originated out of work on EpiDoc, and was opened by one G. Bodard. Notably though, he was not asking for the removal of att.dimensions from elements having to do with date/time. I think there may have been some misreading or misunderstanding of the issue's original intent, which was just to get rid of dimensional attributes on elements where they make no sense. I still think that should happen. The original request was to unbundle att.dimensions from att.editLike and to add it directly only to the elements that need it. 

Mea culpa: I've clearly not been paying sufficient attention to this issue, but for the record, I strongly agree with John, Martin, and Simona about the value of @precision for dates. Possibly part of the solution would be to unbundle @precision from the other att.dimensions attributes.

Hugh

On Tue, Dec 5, 2017 at 1:51 PM, Lou Burnard <[hidden email]> wrote:

Or even maybe reconsider the wisdom of making this mooted change.


On 05/12/17 18:23, Thomas Elliott wrote:
It would, in my view, be helpful for the Council to offer suggestions of
alternative tagging strategies for the use cases others have surfaced on
this thread, and to do so well in advance of the mooted change. Thanks.