Re: recording time period covered by a document

Dario Kampkaspar <[email protected]>
Newsgroups gmane.text.tei.general
Message-ID <[email protected]>
Dear all,

I can think of a number of cases where an element like this might be useful.

For example many (usually more or less periodic) types of list-like 
publications (military list, lists of state personnell or of the 
nobility – like Burke's Peerage or the annuaires in numerous territories 
– almanacs, encyclopdiae etc.) have a certain coverage, usually one or 
more years, special regions, special groups of people/places etc.

As these texts might contain several kinds of these lists (e.g., 
nobility and state personnell while the military is covered in a 
separate volume), my idea would be to have one or more

profileDesc/coverageDesc/coverage

which may contain

- <p> for prose descriptions
- <date> for the temporal coverage
- <place> for the geographical coverage
- <name> for groups of people
- <coverage> for grouping the data along the lines of the document
- @corresp to link it to the relevant part(s) of the text

(Actually, I don't really like 'name', but an element that might contain 
the name of a family, a group of people etc. should not be too specific 
nor should the content of this element be too complex)

It might look sth. like this

<coverage>
     <date when="1780" />
     <coverage corresp="#l1">
         <place>Mecklenburg-Schwerin</place>
     </coverage>
     <coverage corresp="#l2">
         <place>Mecklenburg-Strelitz</place>
         <name>Nobility</name>
     </coverage>
</coverage>

which tells us that the text covers the year 1780 and section #l1 is 
about Mecklenburg-Schwerin in general while #l2 covers 
Mecklenburg-Strelitz and here specifically the nobility.

It might, though, be easier to just repeat the information and forbid 
nesting the coverage element.

In short, I'd strongly support such a feature request.

All best,

Dario


On 18.10.2016 17:53, Martin Holmes wrote:
> Whenever I have to deal with Dublin Core's <coverage> element:
>
> http://dublincore.org/documents/dcmi-terms/#elements-coverage
>
> I feel the need of something like this in TEI. I wonder if there's a 
> good case for a feature request for a new element:
>
> profileDesc/coverageDesc
>
> which would contain date info, geographical info, and perhaps other 
> stuff.
>
> Cheers,
> Martin
>
> On 2016-10-18 02:22 AM, Magdalena Turska wrote:
>> Dear all,
>>
>> I was charged with a task of migrating custom metadata schema into TEI.
>> One of the challenges is representing the period covered in the
>> document, which in the bespoke encoding was represented as
>>
>> |<coverage-start>1945</coverage-start>|
>>
>> |<coverage-end>1946</coverage-end>|
>>
>> It took me quite a while to hunt for the TEI way of expressing similar
>> concept. Following the trail of <creation> element, which I used to
>> represent the date of creation of the original document, I concentrated
>> my search within <profileDesc> and came up
>> with profileDesc/settingDesc/setting/date
>>
>> |<setting> <date from="1945" to="1946"/> </setting>|
>>
>>  I wonder if there's any established practice to encode such a general
>> information about text content? Reaching into language corpora to
>> achieve that seems rather awkward, especially since phrasing of
>> settingDesc element (the setting or settings within which a language
>> interaction takes place, or other places otherwise referred to in a
>> text, edition, or metadata) seems to concentrate very strongly on
>> 'geographical' or locational aspect of the setting. Nevertheless,
>> Guidelines examples of settingDesc tend to record both location and
>> temporal aspect there. I'd appreciate any comments and solutions adopted
>> by projects.
>>
>>
>> Best,
>>
>> Magdalena
>>
>>

-- 
Dario Kampkaspar
Editionsprojekt Karlstadt – Editionsprojekt Rist – DARIAH-DE

Herzog August Bibliothek
Lessingplatz 1
D-38304 Wolfenbüttel

Phone: +49 - 53 31 - 808-321
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.