Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#327 a general purpose <description> alongside traits/states

GREEN
closed-fixed
5
2011-12-01
2011-10-14
Sebastian Rahtz
No

From the meeting of the TEI Ontology SIG at the members meeting 2011-10-14.

There has been some dissatisfaction with the <trait> and <state> distinction for places and persons (and hopefully objects soon). Users find the distinction too fine, or culturally specific. We suggest that

* a new general <description> element be added
* a corresponding model class of model.descriptionLike be added
* model.traitLike and model.stateLike be abandoned, and all their members
be added to model.descriptionLike
* all the current elements be regarded as <description type="{$name}">

Maybe dropping state and trait distinctions is not needed, but we would like the more anonymous version
too. Maybe someone can think of other names for <description>

Discussion

  • Lou Burnard
    Lou Burnard
    2011-11-01

    I have noticed general dissatisfaction with the distinction between trait and state, though it's clear enough. Introducing a third generic element, especially one with a name inviting confusion with all the other "desc" things in the TEI does not seem like a particularly good idea to me. Would it not be better to deprecate either trait or state (preferably the latter)?

     
  • Lou Burnard
    Lou Burnard
    2011-11-01

    • milestone: --> 871209
     
  • BODARD Gabriel
    BODARD Gabriel
    2011-11-04

    I agree with Lou that (a) the distinction, while maybe not universally loved, is at least coherent, and (b) <trait> is a better name for a general element than <description>. If people don't like the distinction, could we not just encourage them to use <trait> for both essential and incidental(*) characteristics of persons, places, things?

    (*) I think this is the better distinction than "temporary" vs "permanent", as some people seem to imagine it.

     
  • Laurent Romary
    Laurent Romary
    2011-11-04

    I'm inline with extending the use of trait as described. Examples should show how temporal constraints (attributes) may be used to move along the incidental/essential continuum.

     
  • Lou Burnard
    Lou Burnard
    2011-11-07

    • assigned_to: rahtz --> jcummings
     
  • Lou Burnard
    Lou Burnard
    2011-11-07

    Agreed that distinction is not always clear; probably state should be chosen as default; trait examples should be simplified; probably traitLike and stateLike classes should be merged (i.e. move existing model.traitLike elements into model.stateLike)

     
  • James Cummings
    James Cummings
    2011-11-07

    I see the tasks assigned as of 2011-11 Council meeting as:

    1) Add prose to Guidelines indicating that where users have a hard time distinguishing between <state> and <trait> that they should use <state> (with @type attribute of course) as a default (on the principle that almost all states and traits in theory can be time-limited). If they do wish to differentiate between those things that are usually time-dependent or not, or 'intrinsic' / 'essential' then they can use both <state> and <trait>. Remarks on trait/state specs should indicate this.

    2) All examples in the Guidelines of trait having date-related attributes should be rationalized. I.e. they should be changed to <state> where appropriate, or they should have the attributes removed. While dating attributes are allowed on <trait> by the schema we should indicate good practice in the examples by only having them on <state>. Remarks should be added to trait to indicate this.

    3) the elements that claim membership of traitLike and stateLike classes be merged into only claiming membership stateLike and any content-models referring to traitLike alone updated to refer to stateLike alone because it is believed these two content models are used identically throughout. (However, this will be checked).

    Anything I'm missing?

     
  • Lou Burnard
    Lou Burnard
    2011-11-09

    • milestone: 871209 --> GREEN
    • status: open --> pending
     
  • James Cummings
    James Cummings
    2011-12-01

    • status: pending --> closed-fixed
     
  • James Cummings
    James Cummings
    2011-12-01

    Committed as of revision 9854. model.*TraitLike removed entirely as it had no more elements and no independent use of its content model. ND chapter prose was tidied up to reflect this, but probably needs a more substantial overhaul at some point. In general, <description> was discarded as an idea and instead <state> chosen as the general purpose element. The distinction with <trait> was preserved but loosened. <trait> should now only be used for when you really are interested in classifying the differences between states and traits. Otherwise, state is the general purpose <description>'like element. The <state type="havingEyeColour"> style of type classification can be used to provide easy output to CIDOC, RDF, etc.