In message "Conal Tuohy" writes: > I'm working on a project which exports biographical data out of a database into TEI P5, and I have a few questions about the new personographic elements. I'm sorry this email is so long! It raises several very interesting topics: maybe you should consider also posting it to TEI-L? I'm just going to reply briefly to the specific questions you ask below rather than on the larger issues raised. > 1) uniquely, occupation is not a member of att.datable. Was that intended? I'm pretty sure that is an error > > 2) occupation and socEcStatus have 2 pointer attributes: a "scheme" (pointing to a taxonomy element) and a "code" (pointing to a category element within the taxonomy). It seems to me that "scheme" is redundant, since the "code" identifies the category and also implicitly identifies the taxonomy (i.e. the ancestor element of the category). Does that make sense? It's true that if @code points to a within a then the @scheme is redundant, since there's only one value-space for identifiers (because they use xml:id). But the taxonomy might not be exhaustively identified within this or any other document. For example, you might want to say "this is code ABC in the Blenkinsop Register of Occupational Diseases" (BROD) without necessarily documenting BROD in its prolix entirety. > > 3) Some elements lack a "type" attribute which I think could be useful. e.g. affiliation doesn't have a type attribute. So it's possible to say that the person with key "xxx" is affiliated to the organisation with key "yyy", but it doesn't seem possible to formally declare and identify the type of affiliation (member, life member, secret member, president, etc) in the TEI. However, because affiliation is a member of att.naming, the tei:affiliation can be linked to an external record by a key attribute, and this external record could provide a type. As well as affiliation, I could see a possible case for adding a type attribute to education ("primary", "secondary") and even to residence ("holiday", "permanent"). Makes sense? In general we've taken the view that is short for . If we now add typing to the elements, as you propose, I suppose this implies a subtyping of the ? So means the same as ? Actually, I chose this one partly because of course you could also argue that presidency isn't a trait but an event! > 4) The element has a @type (e.g. "social", "personal", "other") and also a @name attribute which further defines the type of relationship. It seems to me that this "name" attribute is pretty much equivalent to the "subtype" attribute defined by the att.typed class, and I wonder whether, for consistency's sake, relation shouldn't just be a member of att.typed, and lose the "name" attribute? I have no problem with ading to att.typed and thus giving it subtyping, but the @name attribute is not about subtyping, it's about naming. You might have relations which are typed (or subtyped) in different ways but which are conventionally given the same name. For example you might distinguish matrineal and patrilineal relations in your typology, even though they are both called "cousin". > > 5) In any case, it would be nice if it were possible to document this value somewhere, i.e. to link it to a taxonomy or other formal declaration. The note in the guidelines for the att.typed class says that @type and @subtype may be formally defined in the classification declaration (and incidentally, the note refers spuriously to a element instead of - I assume - ). Ooops. I will track down the reference in att.typed and try to make it less wrong! as currently defined is meant to sit inside , where it describes a classification assigned to a text. I am not sure that we've consiered or should consider extending it to classifying the way the markup oitself is used! The best we have for doing this right now is via the documentation in the in your ODD (which can of course include or other ;links into more formally structured materials such as external ontologies, or even (as Sebastian has already suggested) you could use equiv to point into one from the > > The typology used may be formally defined using the the element of the > within the associated TEI header, or informally as descriptive prose within the element. > from http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-att.typed.html > > Is the documentation intended to mean that the values of the "type" attributes should correspond to the xml:id attributes of category elements in the classDecl? I think it would be good to be explicit about how this formal definition is supposed to work. In particular, I would like to be able to unambiguously, and in a machine-readable way, indicate that a "type" attribute is formally defined. Can anyone tell me how this is supposed to work? As suggested above, I think the paragraph you quote is just a pious hope. I think the way to do it is via an ODD. > > If this isn't feasible, then I'd like to use an attribute whose type is a pointer (to a category) instead, as occupation and socEcStatus do. > The pointer valued attributes are really kinds of normalisation, IU think. What you;re suggesting is certainly a plausible extension of that. > I've had to resort to some awkward encoding for some things e.g. since and have "key" attributes rather than points to categories, if I want to keep a record of what the key means, I have added a taxonomy with categories containing elements with matching keys. If those keys had been pointers I could have pointed directly to a category element. Also, although TEI keys are intended to refer to external database keys etc, there seems no way to specify which database a key corresponds to - in effect there's a single namespace of keys. In the case where you have to refer to multiple database tables, you need to be able to refer to which table they key belongs to (something like the "scheme" and "code" attributes used to point at tei categories). > Yes, this needs more thought. We're not at all consistent in the way @key is used and your example demonstrates clearly how this can lead to confusion. I'd like to mull it over a bit more before responding in more detail though -- and my shift on the help desk has just finished, so I'm going offline now! Lou