<address> should become member of att.typed

[StefanDumont]

A discussion at a workshop on TEI-XML encoding of correspondence resulted in the article "Addresses" by Marjam Trautmann, in which several problems with <address> are being discussed.

One of the problems is that there is no proper way to distinguish multiple addresses on a letter or postcard, e.g. addresses of sender and receiver. At the moment this isn't possible within <address>, since it has no attribute @type and therefore some cumbersome workarounds are necessary (see Trautmann's article for details).

So we ask, if it is possible to make <address> a member of att.typed?

[sydb]

I am not sure I grok (or agree with) the use case listed in the OP. (Nor am I sure I disagree.) But since <address> can obviously be repeated and categorized, and there is a user request, it should (IMHO) be a member att.typed.

But I am concerned that @type is not the attribute that those encoding correspondence really want. Wouldn’t the @type of <address> assert the addressing system used (e.g., by country postal system, by internal business system, etc.)? I think @role or @of would be the attribute for whether this is the address of the sender or recipient, no?

[sabineseifert]

In Trautmann's article there are three cases mentioned: 1 ) sender/addressee: I also think @role fits better than @type. This means, we also need to add <address> to att.naming. 2 ) and 3 ) private address/business address and postal address/e-mail address: For these cases, @type seem to be fitting.

Examples for the Guidelines would be nice which I happily provide.

I am a bit puzzled by the mentioning of @of which I cannot find in the Guidelines?!

[lb42]

It's true that this is probably overloading the use of @type -- and not the only such case. Would a typology of addresses distinguish an address used as a destination differently from one used as a source? If so what happens when the same address originally typed as a source appears later as a destination (maybe those postcards didnt get replies, but probably others did!) So I agree that @type='sender' is suboptimal. But I don't think using @role is quite right either for much the same reason. Suppose the phrase "sent from" appeared in the source before the address, what would you do? Presumably that's not part of the address, so it would not go inside the element. It would ideally be a sibling label element, within some other grouping element .. probably ab or seg . And in the absence of such a label (or even in its presence) you could plausibly attach @type = sender to that grouping element.

---

From: sabine seifert @.> Sent: Monday, October 23, 2023 11:17 AM To: TEIC/TEI @.> Cc: Subscribed @.***> Subject: Re: [TEIC/TEI]

should become member of att.typed (Issue #2459)

In Trautmann's article there are three cases mentioned: 1 ) sender/addressee: I also think @role fits better than @type. This means, we also need to add

to att.naming. 2 ) and 3 ) private address/business address and postal address/e-mail address: For these cases, @type seem to be fitting.

Examples for the Guidelines would be nice which I happily provide.

I am a bit puzzled by the mentioning of @of which I cannot find in the Guidelines?!

— Reply to this email directly, view it on GitHubhttps://github.com/TEIC/TEI/issues/2459#issuecomment-1774870566, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAFBJ5CM73735PH42JCO2JLYAY72PAVCNFSM6AAAAAA3VK3P2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZUHA3TANJWGY. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[lb42]

Also, as i just said on teil why not regard these addresses as special kinds of opener or closer? This wont work if you have other content between them of course but that seems unlikely. In which case the grouping element i referred to above would be opener or closer.

[sydb]

@sabineseifert — True, @of is not in the Guidelines yet, but no reason Council could not add such an attribute to <address>. (And I am guessing that the combination of the thumbs-up emoji to my suggestion of @of or @role and “I don't think using @role is quite right” means that @lb42 likes @of.)

I like @of a bit better than @role, too, but at the moment cannot explain why. In either case, though, I am not really persuaded by @lb42’s argument that it is a problem if the same address is in one place the address of the sender and in another the address of the recipient and in another the address of where they are planning to meet.

P.S. If we went with @role, I think we would have to figure out something other than making <address> a member of att.naming, because even if @key and @ref are OK, @nymRef surely makes no sense, eh?

P.P.S. All this (in my mind) presupposes that <address> becomes a member of att.typed, and the Guidelines discuss the difference between, and provide examples demonstrating the difference between, @type and @whatever-distinguishes-sender-from-recipient-from-something-else.

[lb42]

Actually i think my thumb was up for @role rather than @of which is really quite a weird attribute name, especially for non anglophones i suspect. And my dislike of @role was more for the suggestion of lumbering address with all the other att.naming attributes, but its probably the least worst suggestion so far.

[sabineseifert]

While @role might not be perfect for this case, I would have thought that it's better to use an already existing attribute than to add a completely new one (e.g. @Of) to the 270 we already have just for this one case?! But I am also not sure what to do about @nymRef.

I also don't see a problem in addresses of senders reappearing as addresses of recipients etc.

The question of <address> inside <opener>/<closer> belongs to #2460.

[sydb]

I suppose we could use both <memeberOf key="att.naming"/> and <attDef ident="nymRef" mode="delete"/>, no? (Untested.)

[ebeshero]

Reviewing this discussion, it certainly makes sense to me to add <address> to att.naming. If it were my project, and I were associating a series of addresses with people, I might be concerned about the temporary aspect of residence, but that could be resolved in various ways based on the timespan represented by a project. I'd likely want to use @key or @ref to key an address to someone in a personography list. I'm not sure there's a good reason to introduce @of?

[sydb]

If we add <address> to att.naming it gets @role, not @of. (Everyone in this conversation except me prefers @role to @of, and I do not care much, so I do not think it is really in the running.)

Are you in favor of having a @nymRef on <address>, @ebeshero? (I am not, in large part because I do not see how a <nym> would be used, here.)

If we we want @key, @ref, and @role but not @nymRef (which I suspect is the case, in addition to @type and @subtype, of course), and we do not want to start messing with which classes have which attributes, seems to me we have two choices:

1. Add <address> to att.naming and then delete @nymRef from <address>.
2. Add <address> to att.canonical and then add @role to <address>.

[laurentromary]

I actually could see several scenarios where @nimRef could be useful: e.g. when you record various adresses as provided in sicentific publications (attached to authors) and want to point to a canonical authority, or when you have various adresses in documents but you want to indicate the normalized postal version. Besides, this would make the implementation lighter.

[ebeshero]

To answer @sydb , I do like @role on <address> as a good, clear way to designate the sender vs. receiver. (As in, we can use it to indicate that the role played by a particular address is to designate the sender.)

I'm not sure about @nymRef! @laurentromary ,the idea of pointing to a normalized postal version seems useful, but I'm not sure @nymRef is appropriate.

If we apply @nymRef to an address, doesn't that mean we're thinking of a multi-line address as a kind of name which can have a canonical version? An address is really a series of names/ identifiers for locations, isn't it? I imagine using @nymRef to reconcile a change in designating the name of a street or building--something inside the address, rather than the whole thing.

@key and @ref seem adaptable enough to point from a thing that isn't really a name to a thing that is in order to associate the two. @nymRef may be going too far?

[laurentromary]

@ebeshero you're probably right that this is a little far-fetched and that '@key' and '@ref' may be just appropriate for the task. I ahem actually come across this use case several time recently and wanted to mention it for the record. Thanks you all for the hard job in the council BTW!

[sabineseifert]

Ok, there seems to be a consensus for one of these as @sydb suggested:

1. Add <address> to att.naming and then delete @nymRef from <address>.
2. Add <address> to att.canonical and then add @role to <address>.

I'm not sure about pros and cons regarding each?! Is there a common 'strategy' (e.g. rather delete or add individually)?

[lb42]

Not sure that i entirely agree with either option actually. For me the question is ... Whats the difference between address and placename? In what circs would one be used rather than the other? I see address as a specialised kind of placename which may not necessarily refer to a geographic location eg when its a po box, and which isually has a simple linear structure.

[sydb]

Can you perhaps explain that, @lb42? I do not, at first blush, see how the question of under what circumstances something is a place name vs an address is relevant to the discussion at hand, which is how to differentiate addresses.

But further, the two seem very different to me. I think of a place name as a proper noun for something that occupies a particular space. An address (while it might contain some proper nouns) strikes me as a description in some system (usually postal) of how to get to a place, which place may or may not have a name.

(That does not mean there are not cases where the distinction is not obvious, but there are lots of cases were I would claim the distinction is obvious.)

<placeName>Burnard Towers</placeName>

vs

<address type="obsolete">
  <addrLine>110 Southmoor Road</addrLine>
  <addrLine>Oxford OX26RB</addrLine>
  <addrLine>UK</addrLine>
</address>

[lb42]

Well, we can agree to disagree about the extent to which an address is always and only a placeName. Certainly I agree on the actual issue raised by this ticket (the need to indicate something more about the way an address is to be understood in a given document) : it's better done using @role than @type whether the thing carrying it is an address or a placename. Not sure about your Southmoor road example though: the address "110 Southmoor Road" is not "obsolete" until the house falls down or is renumbered, surely. The obsolescence I assume you are talking about is a property of someone's residence there, not a property of the address itself.

[sydb]

Good point — "obsolete" was not a good choice for the value of @type, there.

So I hope I am summarizing the conversation so far correctly:

• <address> should become a member of att.typed
• <address> should gain @role, @key, & @ref, but not @nymRef (not sure how, yet)

Further, I suggest, there should be prose or a remark or both to explain for what @role, @type, and @ref are each used.