Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allowing listBibl, listPlace and similar in <particDesc> #1772

Closed
FrederikeNeuber opened this issue May 17, 2018 · 7 comments
Closed

Allowing listBibl, listPlace and similar in <particDesc> #1772

FrederikeNeuber opened this issue May 17, 2018 · 7 comments
Assignees
@peterstadler
Labels
Status: Needs Discussion
Milestone
Guidelines 3.6.0

Comments

@FrederikeNeuber
Copy link

FrederikeNeuber commented May 17, 2018 •
edited by lb42
Loading

I opened a thread on this a while ago on the TEI list (http://tei-l.970651.n3.nabble.com/smth-like-quot-particDesc-quot-for-mentions-of-places-and-works-td4030401.html) and now I'd like to officially suggest the inclusion of other lists of entities (esp. listBibl and listPlace) in <particDesc>.
@lb42
Copy link
Member

lb42 commented May 18, 2018

It's hard to see how a book or a place could be a participant in a text in any meaningful way. If the purpose is simply to have one place to hold all kinds of different reference lists or authority files for your corpus, maybe a simpler solution would be to define a separate TEI document to hold them. Then you could put the lists in the body of that document. References to books, people, places etc in one or more documentscould then reference the items in the appropriate list in that "authority document". There's no need for the lists to be in the header, after all.

@arojascastro
Copy link

listPlace can be a child of settingDesc. Why not using it to store a list of places?

On the other hand, maybe textDesc could also include a list of bibliographic entries and a list of events mentioned in the text. That would be nice if you do not want to separate them and create another document.

@ebeshero
Copy link
Member

@lb42 , you said it's hard to see how books and places can be said to "participate" in a text. Then again, when people are represented in a text as "participants" in <particDesc> we don't always mean that they are participants (as in speakers or human agents). Our description of <particDesc> says that it "describes the identifiable speakers, voices, or other participants in any kind of text or other persons named or otherwise referred to in a text, edition, or metadata." The second half of that is relevant here: "other persons named or otherwise referred to". So long as we're using <particDesc> to store named persons and considering the act of naming to be a kind of participation in a text, I think other named entities have room to be represented.

In the e-mail listserv discussion, @martindholmes pointed out that <sourceDesc> might be a first consideration here, but would definitely not be appropriate when the texts are referenced and aren't source documents.

If particDesc isn't the right place for this, what is?

@ebeshero
Copy link
Member

@peterstadler : any thoughts on this?

@peterstadler
Copy link
Member

A bit late to the party, but here are my 2c:

My impression is that the TEI Guidelines (for historic and provenance reasons?) try to distinguish between list*s related to setting (socio-linguistic), sources (cataloguing and codicology) and participants (drama?). The more common use case nowadays seems to be more of an uncategorized *ography, i.e. encoders (including me) are simply looking for a way to identify all sorts of entities (and events) and store them in one place (without distinguishing in the first place between e.g. places related to the source and those mentioned in the text).

I agree with @lb42 that a dedicated document, featuring all those lists in its <body>, is a proper way to achieve this, … but

  • for small projects (without the overhead of centralized *ographies),
  • for pedagogic reasons,
  • for a more modern RDF-like (i.e. define entities and then relate them, rather than creating relations by putting them in some hierarchical context),
  • and generally for facilitating a more streamlined encoding,

I'm supporting the request

@martindholmes
Copy link
Contributor

I'd much prefer to have a <linkedDataBlock> or <ldb> element as we've been discussing for years. All the list* stuff should be allowed in there, rather than making ad-hoc additions to particDesc, which does have a purpose of its own.

@peterstadler
Copy link
Member

In face to face 2019-05-07 Council decides to defer this to the standoff proposal (#374 #1745). As @martindholmes noted, the intended <standoff> (or whatever the name will be) element will be the place for those lists.

@martinascholger martinascholger added this to the Guidelines 3.6.0 milestone Jun 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@peterstadler peterstadler

Labels
Status: Needs Discussion
Projects
None yet
Milestone
Guidelines 3.6.0
Development

No branches or pull requests
7 participants
@lb42 @peterstadler @martindholmes @ebeshero @arojascastro @FrederikeNeuber @martinascholger