place and org should claim membership of att.datable

[jamescummings]

Organisations and places, along with most other named, might exist only for a particular duration. While with person there are specific elements inside such as birth and death, there is nothing similar for places and organisations and places. One solution is to create child event elements for the creation and dissolution of an organisation, or the founding and destruction of a place, and that is good when one also wants to provide additional information about the creation/dissolution/founding/destruction of the entity, but when you just want to record the date, this seems like a messing inconvenience. Events are already claim membership of att.datable.

If done, one could easily add notBefore/notAfter/from/to to indicate duration of the existence of a place. So, assuming you don't want to supply more details, instead of having to do something like this:

               <place xml:id="at001">
                     <placeName type="standard">Atlantis</placeName>
                     <event type="founding" notBefore="-9600"><ab>Founding of Atlantis</ab></event>
                     <event type="destruction" notAfter="-0360"><ab>destruction of Atlantis</ab></event>
                     <!-- etc. -->
               </place>

one could just do:

               <place xml:id="at002" notBefore="-9600" notAfter="-0360">
                     <placeName type="standard">Atlantis</placeName>
                     <!-- etc. -->
               </place>

If council thought this was an ok idea, I'm happy to implement it consistently across all named entities.

[sydb]

Assigning to @trishaoconnor to move this issue through a discussion in Council. Presuming the idea is approved, will re-assign to @jamescummings to do the work in a branch and issue a PR.

[skurzinz]

We've seen with event that if you need to record more than a start and end datetime, we either need n child desc/dates (e.g. when recording different claims on when an event took place) or nested event elements.

What about person? We have birth/death there, which would overlap with the att.datable attributes. But implementing this consistently among the *ography elements as @jamescummings suggests would probably mean that person should also made datable. If so: Should we make this a strict alternative (either att.datable or birth/death)?

[ebeshero]

@skurzinz The <person> element is already very well-equipped for containing elements in att.datable, with not only <birth> and <death> but also <persName>, <event>, <state>, and even <trait>. I would not want to remove the expressiveness of these elements working together in the encoding of events and transformations of various kinds. You could see <birth> and <death> as syntactic sugar for <event>, but considering the variety of datable concepts associated with personal existence, I think we shouldn't remove the ability to work with these simply to include <person> in att.datable. I think it's better to leave <person> out of att.datable, and guide people toward the precise expression of what they're dating when applying dates to the concept here.

The encoding developed for <person> seems optimized for precision and expressiveness of a variety of datable conditions. Should it help to inform the encoding of <place> and <event>?

Maybe what's needed by all of these elements is a generalized/adaptable <state> element. I see that <place> as well as <placeName> can contain <state>, but only <eventName> can have <state>. I wonder if it would help enrich what we can say of a recurring event to be able to apply <state> to it?

[ebeshero]

Some of that was a bit off the original ticket, I know. But as @skurzinz points out, it's important we consider how these concepts of person, organization, place, and event relate to each other in temporality.

After all that thinking about <person>, I am hesitating over including <place> and <org> in att.datable because it introduces an ambiguity when dates are applied to concepts rather than names. Isn't it sufficient that <placeName> and <orgName> are members of att.datable? Places and organizations change their names often enough that applying the attributes on the whole concept of the organization or place seems to oversimplify the concept.

[skurzinz]

Isn't it sufficient that <placeName> and <orgName> are members of att.datable? Places and organizations change their names often enough that applying the attributes on the whole concept of the organization or place seems to oversimplify the concept.

I’d say those are two different scenarios: In the one, an entity begins/ends to exist (which is quite parallel to the att.datable on event), the other signifies specific traits related to this entity and their lifespan. So, while a castle was destroyed and physically ceased to exist (<place xml:id="thiscastle" to="1453">), it could still have a <placeName from="1453">ruins of thiscastle</placeName>.

Similarly, an org may have several orgNames with specific att.datable denoting each name between dates, and finally it is dissolved and ceases to exist (that would be <org xml:id="thisorg" to="1918-11-11"/>)

What makes the proposal by @jamescummings tempting in my view is the ease of modeling the non-complicated low-hanging fruit in a generic way: Start with @from and @to processing, and then take care of the special cases that need attention. I would not mind having this on person as well, as it removes the necessity to parse birth/death et al. for person entities.
"Give me all EOL dates for all named entities, be they objects, places, persons, orgs or events" would be much easier to formulate: //standOff//*[contains(name(), 'list')]//@*[name()=('to','notAfter')].

(I just noticed that similar to CIDOC "beginning_of_begin" and "end_of_begin" you can do the same on person:

<person xml:id="KarlWilhelmJerusalem"> 
<!-- this would be att.datable: notAfter="1772-10-30", and not contradictory to the details in the child elements -->
            <death from="1772-10-29" to="1772-10-30"/>
            <event when="1772-10-29"><label>Jerusalem's suicide</label></event>
            <event when="1772-10-30"><label>Jerusalem dies</label></event>
</person>

Those finely grained coding options are good to have.)

[tuurma]

I support the idea of adding place, org, and also person to att.datable, seeing it as a very useful, generic way to provide (and determine in processing) the range of dates where these entities existed. I see it as a good step towards consistent generic model and interoperability.

Nevertheless, I don't think it should preclude the use of child elements like birth/date/event with their own dating attributes to cover the details and complexities of the source material and its interpretation.