Why <org> cannot contain <date>?

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

Why <org> cannot contain <date>?

ANTONIO ROJAS CASTRO
Hello there,

I searched the mailing list and I could not find out why <org> cannot have a <date> element as a direct child. This might be useful if you want to document the life of an organization or society - for instance the Café Littéraire Bern apparently was active from 1760 to 1770. 

At the moment, I am using org/note/date, but I think org/date would be nicer. Is there any reason to not to allow it? 

Thanks in advance.

-- 
Dr. Antonio Rojas Castro
Post-doctoral Researcher, Cologne Center for eHumanities
Editor, The Programming Historian en español
Reply | Threaded
Open this post in threaded view
|

Re: Why <org> cannot contain <date>?

James Cummings-5

Hi Antonio,


Good question. I was going to answer saying that org/person/place were members of att.datable and thus could have dating attributes on them and that this might be a better approach, but I'm entirely wrong about that. (I think it would be useful if they did and think I added them in a TEI ODD for one project, hence my misremembering.)


If I *had* to fabricate a reason as a post-hoc rationalisation for why none of the named entity metadata containers of person/place/org allow a direct <date> as a child, I'd probably fall back on suggesting it isn't the entities which have dates but states/traits/events that happen to them. For example, it isn't the organisation that has dates, but its state of being active which does.


===

<org xml:id="CLB001">
  <orgName type="main">Café Littéraire Bern</orgName>
  <state type="active" from="1760" to="1770"><p>Active from 1760 to 1770</p></state>
</org>
===


But as part of a long-standing desire to provide more rationalisation in the named-entity metadata containers like person/place/org having them be a member of att.datable (and thus get @notBefore/@notAfter/@when/@from/@to etc.) to stand in for a shortcut method of expressing the dates of when the entity is said to have existed, sounds pretty reasonable to me. 


Best wishes,

James 


--

Dr James Cummings, [hidden email]

School of English Literature, Language, and Linguistics, Newcastle University


From: TEI (Text Encoding Initiative) public discussion list <[hidden email]> on behalf of Antonio Rojas Castro <[hidden email]>
Sent: 19 April 2018 14:26:35
To: [hidden email]
Subject: Why <org> cannot contain <date>?
 
Hello there,

I searched the mailing list and I could not find out why <org> cannot have a <date> element as a direct child. This might be useful if you want to document the life of an organization or society - for instance the Café Littéraire Bern apparently was active from 1760 to 1770. 

At the moment, I am using org/note/date, but I think org/date would be nicer. Is there any reason to not to allow it? 

Thanks in advance.

-- 
Dr. Antonio Rojas Castro
Post-doctoral Researcher, Cologne Center for eHumanities
Editor, The Programming Historian en español
Reply | Threaded
Open this post in threaded view
|

Re: Why <org> cannot contain <date>?

Syd Bauman-10
In reply to this post by ANTONIO ROJAS CASTRO
Interesting point. Wouldn't <birth> & <death> or <floruit> be the
way to express "this organization was active from 1760 to 1770"?

I'm asking not in order to provide a solution to your current problem
-- those elements are not allowed inside <org> at the moment, either
-- but rather as fodder for work on <org> that we (TEI Council) plan
to start in late spring or early summer, namely addressing the
content of <person>, <place>, <org>, and maybe <nym>. At the moment I
would expect that once that process is over, <org> would allow
<birth>, <death>, and <floruit> children. But (at the moment) <date>
is not on the list of elements likely to be added to <org>.

> I searched the mailing list and I could not find out why <org>
> cannot have a <date> element as a direct child. This might be
> useful if you want to document the life of an organization or
> society - for instance the Café Littéraire Bern apparently was
> active from 1760 to 1770.
>
> At the moment, I am using org/note/date, but I think org/date would
> be nicer. Is there any reason to not to allow it?
Reply | Threaded
Open this post in threaded view
|

Re: Why <org> cannot contain <date>?

Lou Burnard-6
In reply to this post by James Cummings-5
Hi James. I don't agree with you!
<org> and other entities should *not* be datable, precisely for the reasons you state: the date attaches to some property of the entity, not the entity itself. Rome was not built in a day, and the entity defining Roma therefore has a "building" property which is datable, just as a "destruction" property might have. But Rome itself ? The only dates you could plausibly attach to it would be relate to its existence *as a concept* not the historical events associated with it.

As you say, an organization doesnt have dates, though its various activities do.

 
On 19/04/18 15:41, James Cummings wrote:

Hi Antonio,


Good question. I was going to answer saying that org/person/place were members of att.datable and thus could have dating attributes on them and that this might be a better approach, but I'm entirely wrong about that. (I think it would be useful if they did and think I added them in a TEI ODD for one project, hence my misremembering.)


If I *had* to fabricate a reason as a post-hoc rationalisation for why none of the named entity metadata containers of person/place/org allow a direct <date> as a child, I'd probably fall back on suggesting it isn't the entities which have dates but states/traits/events that happen to them. For example, it isn't the organisation that has dates, but its state of being active which does.


===

<org xml:id="CLB001">
  <orgName type="main">Café Littéraire Bern</orgName>
  <state type="active" from="1760" to="1770"><p>Active from 1760 to 1770</p></state>
</org>
===


But as part of a long-standing desire to provide more rationalisation in the named-entity metadata containers like person/place/org having them be a member of att.datable (and thus get @notBefore/@notAfter/@when/@from/@to etc.) to stand in for a shortcut method of expressing the dates of when the entity is said to have existed, sounds pretty reasonable to me. 


Best wishes,

James 


--

Dr James Cummings, [hidden email]

School of English Literature, Language, and Linguistics, Newcastle University


From: TEI (Text Encoding Initiative) public discussion list [hidden email] on behalf of Antonio Rojas Castro [hidden email]
Sent: 19 April 2018 14:26:35
To: [hidden email]
Subject: Why <org> cannot contain <date>?
 
Hello there,

I searched the mailing list and I could not find out why <org> cannot have a <date> element as a direct child. This might be useful if you want to document the life of an organization or society - for instance the Café Littéraire Bern apparently was active from 1760 to 1770. 

At the moment, I am using org/note/date, but I think org/date would be nicer. Is there any reason to not to allow it? 

Thanks in advance.

-- 
Dr. Antonio Rojas Castro
Post-doctoral Researcher, Cologne Center for eHumanities
Editor, The Programming Historian en español


Reply | Threaded
Open this post in threaded view
|

Re: Why <org> cannot contain <date>?

Lou Burnard-6
In reply to this post by Syd Bauman-10
<floruit> makes sense for <org>s, but <birth> and <death> ? A bit
poetic, Syd!


On 19/04/18 16:01, Syd Bauman wrote:

> Interesting point. Wouldn't <birth> & <death> or <floruit> be the
> way to express "this organization was active from 1760 to 1770"?
>
> I'm asking not in order to provide a solution to your current problem
> -- those elements are not allowed inside <org> at the moment, either
> -- but rather as fodder for work on <org> that we (TEI Council) plan
> to start in late spring or early summer, namely addressing the
> content of <person>, <place>, <org>, and maybe <nym>. At the moment I
> would expect that once that process is over, <org> would allow
> <birth>, <death>, and <floruit> children. But (at the moment) <date>
> is not on the list of elements likely to be added to <org>.
>
>> I searched the mailing list and I could not find out why <org>
>> cannot have a <date> element as a direct child. This might be
>> useful if you want to document the life of an organization or
>> society - for instance the Café Littéraire Bern apparently was
>> active from 1760 to 1770.
>>
>> At the moment, I am using org/note/date, but I think org/date would
>> be nicer. Is there any reason to not to allow it?
Reply | Threaded
Open this post in threaded view
|

Re: Why <org> cannot contain <date>?

richard light
In reply to this post by Syd Bauman-10

On 19/04/2018 16:01, Syd Bauman wrote:
I'm asking not in order to provide a solution to your current problem
-- those elements are not allowed inside <org> at the moment, either
-- but rather as fodder for work on <org> that we (TEI Council) plan
to start in late spring or early summer, namely addressing the
content of <person>, <place>, <org>, and maybe <nym>. At the moment I
would expect that once that process is over, <org> would allow
<birth>, <death>, and <floruit> children. But (at the moment) <date>
is not on the list of elements likely to be added to <org>.
Are you looking for volunteers to help with that exercise?  I think this would be of considerable interest to the Linked Pasts working group, who are aiming to develop guidelines for interoperable expression of person and place data.  Also, the point Lou makes about needing an event/activity context for the date suggests that a sprinkling of ideas from the CIDOC CRM SIG [2] wouldn't go amiss.  You may have noted my largely futile attempts to extract prosopographical Linked Data directly from <listPerson> elements in publicly available TEI resources.  I suspect I won't be the last to tread this path ...

Richard

[1] http://commons.pelagios.org/groups/linked-pasts/
[2] http://www.cidoc-crm.org/
--
Richard Light
Reply | Threaded
Open this post in threaded view
|

Re: Why <org> cannot contain <date>?

James Cummings-5
In reply to this post by Lou Burnard-6

Hi Lou,


Colour me surprised -- though I'm not sure I agree with me either! ;-) I can see an argument for having dates on org/person/place as a shortcut, and only a shortcut for only the existence of the entity, but yes, if there are appropriate elements available inside I prefer that. (I like the suggestion of <floruit> for an organisation... where used correctly that might be handy. Organisations do have periods where they produce lots of output and then go into a decline of activity.) But do agree that using child elements to indicate the start and end of certain states/traits/events is more accurate. (Thus the necessity of rationalising these across org/person/place and eventually object.)


Best wishes,

James 


--

Dr James Cummings, [hidden email]

School of English Literature, Language, and Linguistics, Newcastle University




From: TEI (Text Encoding Initiative) public discussion list <[hidden email]> on behalf of Lou Burnard <[hidden email]>
Sent: 19 April 2018 16:04
To: [hidden email]
Subject: Re: Why <org> cannot contain <date>?
 
Hi James. I don't agree with you!
<org> and other entities should *not* be datable, precisely for the reasons you state: the date attaches to some property of the entity, not the entity itself. Rome was not built in a day, and the entity defining Roma therefore has a "building" property which is datable, just as a "destruction" property might have. But Rome itself ? The only dates you could plausibly attach to it would be relate to its existence *as a concept* not the historical events associated with it.

As you say, an organization doesnt have dates, though its various activities do.

 
On 19/04/18 15:41, James Cummings wrote:

Hi Antonio,


Good question. I was going to answer saying that org/person/place were members of att.datable and thus could have dating attributes on them and that this might be a better approach, but I'm entirely wrong about that. (I think it would be useful if they did and think I added them in a TEI ODD for one project, hence my misremembering.)


If I *had* to fabricate a reason as a post-hoc rationalisation for why none of the named entity metadata containers of person/place/org allow a direct <date> as a child, I'd probably fall back on suggesting it isn't the entities which have dates but states/traits/events that happen to them. For example, it isn't the organisation that has dates, but its state of being active which does.


===

<org xml:id="CLB001">
  <orgName type="main">Café Littéraire Bern</orgName>
  <state type="active" from="1760" to="1770"><p>Active from 1760 to 1770</p></state>
</org>
===


But as part of a long-standing desire to provide more rationalisation in the named-entity metadata containers like person/place/org having them be a member of att.datable (and thus get @notBefore/@notAfter/@when/@from/@to etc.) to stand in for a shortcut method of expressing the dates of when the entity is said to have existed, sounds pretty reasonable to me. 


Best wishes,

James 


--

Dr James Cummings, [hidden email]

School of English Literature, Language, and Linguistics, Newcastle University


From: TEI (Text Encoding Initiative) public discussion list [hidden email] on behalf of Antonio Rojas Castro [hidden email]
Sent: 19 April 2018 14:26:35
To: [hidden email]
Subject: Why <org> cannot contain <date>?
 
Hello there,

I searched the mailing list and I could not find out why <org> cannot have a <date> element as a direct child. This might be useful if you want to document the life of an organization or society - for instance the Café Littéraire Bern apparently was active from 1760 to 1770. 

At the moment, I am using org/note/date, but I think org/date would be nicer. Is there any reason to not to allow it? 

Thanks in advance.

-- 
Dr. Antonio Rojas Castro
Post-doctoral Researcher, Cologne Center for eHumanities
Editor, The Programming Historian en español


Reply | Threaded
Open this post in threaded view
|

Re: Why <org> cannot contain <date>?

Janelle Jenstad

Hi James, et al,

 

I don’t have much to say about <org>, but MoEML (mapoflondon.uvic.ca) has been wrestling for a while with how to indicate the temporal limits of <place>. For me (and for many geohumanists, but certainly not all), space is defined by a set of geocoordinates (lat, long, height above sea level), and different places occupy spaces over time. Places often come into being when humans do things (build, have a battle, etc), which we sometimes remember and sometimes don’t. But the idea of place has temporal limits that don’t always coincide with datable events.  If att.datable were available on <place>, it would give us another option for dealing with the challenge of places that move to new spaces, spaces that are occupied by multiple places over time, buildings that change identity/purpose and therefore (by some ways of thinking) become new places, and places whose existence is known from textual references or archaeological finds (in which case @notBefore and @notAfter would be very handy). If one is building a historical gazetteer for an era (London 1500-1700, in our case), one has to account for a succession of places on a particular space. The imaginative force of a place can persist and even overlap with a new place on that space. The ability to use geocoordinates and temporal attributes in combination on <place> would be very powerful!

 

If there’s the possibility of a feature request, I’ll write up my thoughts more clearly and give some concrete examples.

 

All best,

Janelle

 

Janelle Jenstad, Associate Professor, Department of English

Coordinating Editor, Internet Shakespeare Editions

Director, The Map of Early Modern London

University of Victoria

Skype:  janelle.jenstad; Time zone: UTC -8

Book appointments: https://janelle-jenstad.youcanbook.me/

 

 

 

 

 

From: TEI (Text Encoding Initiative) public discussion list <[hidden email]> On Behalf Of James Cummings
Sent: April 19, 2018 9:32 AM
To: [hidden email]
Subject: Re: Why <org> cannot contain <date>?

 

Hi Lou,

 

Colour me surprised -- though I'm not sure I agree with me either! ;-) I can see an argument for having dates on org/person/place as a shortcut, and only a shortcut for only the existence of the entity, but yes, if there are appropriate elements available inside I prefer that. (I like the suggestion of <floruit> for an organisation... where used correctly that might be handy. Organisations do have periods where they produce lots of output and then go into a decline of activity.) But do agree that using child elements to indicate the start and end of certain states/traits/events is more accurate. (Thus the necessity of rationalising these across org/person/place and eventually object.)

 

Best wishes,

James 

 

--

Dr James Cummings, [hidden email]

School of English Literature, Language, and Linguistics, Newcastle University

 


From: TEI (Text Encoding Initiative) public discussion list <[hidden email]> on behalf of Lou Burnard <[hidden email]>
Sent: 19 April 2018 16:04
To: [hidden email]
Subject: Re: Why <org> cannot contain <date>?

 

Hi James. I don't agree with you!
<org> and other entities should *not* be datable, precisely for the reasons you state: the date attaches to some property of the entity, not the entity itself. Rome was not built in a day, and the entity defining Roma therefore has a "building" property which is datable, just as a "destruction" property might have. But Rome itself ? The only dates you could plausibly attach to it would be relate to its existence *as a concept* not the historical events associated with it.

As you say, an organization doesnt have dates, though its various activities do.

 
On 19/04/18 15:41, James Cummings wrote:

Hi Antonio,

 

Good question. I was going to answer saying that org/person/place were members of att.datable and thus could have dating attributes on them and that this might be a better approach, but I'm entirely wrong about that. (I think it would be useful if they did and think I added them in a TEI ODD for one project, hence my misremembering.)

 

If I *had* to fabricate a reason as a post-hoc rationalisation for why none of the named entity metadata containers of person/place/org allow a direct <date> as a child, I'd probably fall back on suggesting it isn't the entities which have dates but states/traits/events that happen to them. For example, it isn't the organisation that has dates, but its state of being active which does.

 

===

<org xml:id="CLB001">

  <orgName type="main">Café Littéraire Bern</orgName>

  <state type="active" from="1760" to="1770"><p>Active from 1760 to 1770</p></state>

</org>

===

 

But as part of a long-standing desire to provide more rationalisation in the named-entity metadata containers like person/place/org having them be a member of att.datable (and thus get @notBefore/@notAfter/@when/@from/@to etc.) to stand in for a shortcut method of expressing the dates of when the entity is said to have existed, sounds pretty reasonable to me. 

 

Best wishes,

James 

 

--

Dr James Cummings, [hidden email]

School of English Literature, Language, and Linguistics, Newcastle University


From: TEI (Text Encoding Initiative) public discussion list [hidden email] on behalf of Antonio Rojas Castro [hidden email]
Sent: 19 April 2018 14:26:35
To: [hidden email]
Subject: Why <org> cannot contain <date>?

 

Hello there,

 

I searched the mailing list and I could not find out why <org> cannot have a <date> element as a direct child. This might be useful if you want to document the life of an organization or society - for instance the Café Littéraire Bern apparently was active from 1760 to 1770. 

 

At the moment, I am using org/note/date, but I think org/date would be nicer. Is there any reason to not to allow it? 

 

Thanks in advance.

 

-- 
Dr. Antonio Rojas Castro
Post-doctoral Researcher, Cologne Center for eHumanities

Editor, The Programming Historian en español

 

Reply | Threaded
Open this post in threaded view
|

Re: Why <org> cannot contain <date>?

ANTONIO ROJAS CASTRO
Hello again,

I thank you for your replies. 

I have 853 descriptions of organizations and 2903 descriptions of places. The editors used to represent the following information:

*Organizations*
- identifier
- canonical name and alternative names
- place
- date
- bibliographical reference (sometimes)

*Places*
- identifier
- canonical name and alternative names
- geographical coordinates
- date
- bibliographical reference (sometimes)

What I mean by this is that these both entities are not related to any event in my dataset — unless we accept that *existence* is an event, which I think it is not correct from a philosophical point of view (but maybe I’m wrong). On the other hand, I understand that we are trying to get closer to CIDOC-CR conceptual model, which is focused on events.

Thus I agree with Janelle’s opinion about allowing <date> within <org> and <place> — not within <person> because for that we already have birth/date and death/date. 

For me it is not very coherent to record a date in a <status> or <event> element and also it is more difficult to predict for other people. For instance, imagine that someone wants to write xslt to create a list of dates, s/he would look for <date> probably. 

Lastly, I am open to discuss this further or to help to improve the modeling of entities as well in the future.

Best,

-- 
Dr. Antonio Rojas Castro
Post-doctoral Researcher, Cologne Center for eHumanities
Editor, The Programming Historian en español

De: Janelle Jenstad [hidden email]
Responder: Janelle Jenstad [hidden email]
Filtrar por fecha: 19 de abril de 2018 at 19:12:10
Para: [hidden email] [hidden email]
Asunto:  Re: Why cannot contain ?

Hi James, et al,

 

I don’t have much to say about <org>, but MoEML (mapoflondon.uvic.ca) has been wrestling for a while with how to indicate the temporal limits of <place>. For me (and for many geohumanists, but certainly not all), space is defined by a set of geocoordinates (lat, long, height above sea level), and different places occupy spaces over time. Places often come into being when humans do things (build, have a battle, etc), which we sometimes remember and sometimes don’t. But the idea of place has temporal limits that don’t always coincide with datable events.  If att.datable were available on <place>, it would give us another option for dealing with the challenge of places that move to new spaces, spaces that are occupied by multiple places over time, buildings that change identity/purpose and therefore (by some ways of thinking) become new places, and places whose existence is known from textual references or archaeological finds (in which case @notBefore and @notAfter would be very handy). If one is building a historical gazetteer for an era (London 1500-1700, in our case), one has to account for a succession of places on a particular space. The imaginative force of a place can persist and even overlap with a new place on that space. The ability to use geocoordinates and temporal attributes in combination on <place> would be very powerful!

 

If there’s the possibility of a feature request, I’ll write up my thoughts more clearly and give some concrete examples.

 

All best,

Janelle

 

Janelle Jenstad, Associate Professor, Department of English

Coordinating Editor, Internet Shakespeare Editions

Director, The Map of Early Modern London

University of Victoria

Skype:  janelle.jenstad; Time zone: UTC -8

Book appointments: https://janelle-jenstad.youcanbook.me/

 

 

 

 

 

From: TEI (Text Encoding Initiative) public discussion list <[hidden email]> On Behalf Of James Cummings
Sent: April 19, 2018 9:32 AM
To: [hidden email]
Subject: Re: Why <org> cannot contain <date>?

 

Hi Lou,

 

Colour me surprised -- though I'm not sure I agree with me either! ;-) I can see an argument for having dates on org/person/place as a shortcut, and only a shortcut for only the existence of the entity, but yes, if there are appropriate elements available inside I prefer that. (I like the suggestion of <floruit> for an organisation... where used correctly that might be handy. Organisations do have periods where they produce lots of output and then go into a decline of activity.) But do agree that using child elements to indicate the start and end of certain states/traits/events is more accurate. (Thus the necessity of rationalising these across org/person/place and eventually object.)

 

Best wishes,

James 

 

--

Dr James Cummings, [hidden email]

School of English Literature, Language, and Linguistics, Newcastle University

 


From: TEI (Text Encoding Initiative) public discussion list <[hidden email]> on behalf of Lou Burnard <[hidden email]>
Sent: 19 April 2018 16:04
To: [hidden email]
Subject: Re: Why <org> cannot contain <date>?

 

Hi James. I don't agree with you!
<org> and other entities should *not* be datable, precisely for the reasons you state: the date attaches to some property of the entity, not the entity itself. Rome was not built in a day, and the entity defining Roma therefore has a "building" property which is datable, just as a "destruction" property might have. But Rome itself ? The only dates you could plausibly attach to it would be relate to its existence *as a concept* not the historical events associated with it.

As you say, an organization doesnt have dates, though its various activities do.

 
On 19/04/18 15:41, James Cummings wrote:

Hi Antonio,

 

Good question. I was going to answer saying that org/person/place were members of att.datable and thus could have dating attributes on them and that this might be a better approach, but I'm entirely wrong about that. (I think it would be useful if they did and think I added them in a TEI ODD for one project, hence my misremembering.)

 

If I *had* to fabricate a reason as a post-hoc rationalisation for why none of the named entity metadata containers of person/place/org allow a direct <date> as a child, I'd probably fall back on suggesting it isn't the entities which have dates but states/traits/events that happen to them. For example, it isn't the organisation that has dates, but its state of being active which does.

 

===

<org xml:id="CLB001">

  <orgName type="main">Café Littéraire Bern</orgName>

  <state type="active" from="1760" to="1770"><p>Active from 1760 to 1770</p></state>

</org>

===

 

But as part of a long-standing desire to provide more rationalisation in the named-entity metadata containers like person/place/org having them be a member of att.datable (and thus get @notBefore/@notAfter/@when/@from/@to etc.) to stand in for a shortcut method of expressing the dates of when the entity is said to have existed, sounds pretty reasonable to me. 

 

Best wishes,

James 

 

--

Dr James Cummings, [hidden email]

School of English Literature, Language, and Linguistics, Newcastle University


From: TEI (Text Encoding Initiative) public discussion list [hidden email] on behalf of Antonio Rojas Castro [hidden email]
Sent: 19 April 2018 14:26:35
To: [hidden email]
Subject: Why <org> cannot contain <date>?

 

Hello there,

 

I searched the mailing list and I could not find out why <org> cannot have a <date> element as a direct child. This might be useful if you want to document the life of an organization or society - for instance the Café Littéraire Bern apparently was active from 1760 to 1770. 

 

At the moment, I am using org/note/date, but I think org/date would be nicer. Is there any reason to not to allow it? 

 

Thanks in advance.

 

-- 
Dr. Antonio Rojas Castro
Post-doctoral Researcher, Cologne Center for eHumanities

Editor, The Programming Historian en español