<respStmt> in <titleStmt> Vs. <editionStmt>

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

<respStmt> in <titleStmt> Vs. <editionStmt>

Tracey El Hajj

Hi all,


In the <teiHeader> we have various options to include <respStmt>s. It is conventional that all <respStmt>s go in <titleStmt>, but when is it better to include them in <editionStmt> instead?


​Thanks,

Tracey​


Tracey El Hajj
PhD Candidate | English
Junior Programmer | MoEML
Tutor | CAC
University of Victoria

Please consider the environment before printing this email
Reply | Threaded
Open this post in threaded view
|

Textual Communities Launch

Robinson, Peter
We are pleased to announce today the full public release of Textual Communities. Textual Communities is an environment for the collaborative online creation of scholarly editions.

There are two public versions of Textual Communities:

·      The production version, https://textualcommunities.org

·      The sandbox version, https://textualcommunitessandbox.org

You can create your own account on the sandbox version, and experiment with it.

Textual Communities has the following distinctive features:
·      It is not an adaptation of any other system, but is built anew from the ground up;

·      It understands text as a collection of leaves distributed across a document tree and an entity tree. Accordingly, it can both present text page by page (or line by line), as parts of a document tree, and it can present text entity by entity, as a hierarchy of acts of eommunication  (hence, line 1 of the General Prologue of the Canterbury Tales), as parts of an entity tree;

·      It offers powerful collation tools, CollateX and the Collation Editor, permitting precise tailoring of the collation of any entity in muliple documents;

·      It includes tools for managing collaboration: to invite, supervise and monitor multiple collaborators;

·      It includes an IIIF image server, and can create editiable documents from IIIF manifests;

·      It provides an API giving access to all materials through URI resource descriptors.

The documentation at https://wiki.usask.ca/display/TC/Textual+Communities offers a “Getting Started” guide, and various other documents.

We are grateful for the support of the Canada Foundation for Innovation, the Social Sciences and Humanities Research Council of Canada, and the University of Saskatchewan.


The Textual Communities Team, email [hidden email]

ADHO conference 2018,  Mexico City, 28 June 2018.


The text of the talk presenting Textual Communities at the ADHO conference is available at https://wiki.usask.ca/display/TC/Creating+and+Implementing+an+Ontology+of+Documents+and+Texts

Reply | Threaded
Open this post in threaded view
|

Re: <respStmt> in <titleStmt> Vs. <editionStmt>

Tracey El Hajj
In reply to this post by Tracey El Hajj

​With regards to the previous question:


When we are dealing with primary sources, we are looking at various options for encoding responsibilities. The first issue that I am looking at is a structural distinction between the original source's credits and the digital edition's (ours), which is rarely a 1st generation digital edition. 


The conventional way is to add <respStmt> in <fileDesc> <titleStmt>, commenting out the difference.

For instance, when assigning <respStmt> for the original work, we add a comment as such: <!!-- Primary respStmt belonging to the text -->. When encoding information about the digital edition, the following comment can be an example: <!-- Modern contributors, encoders, and transcribers -->.


<fileDesc>

    <titleStmt>

        <title></title>

        <!!-- Primary respStmt belonging to the text -->

        <respStmt></respStmt>

        <!-- Modern contributors, encoders, and transcribers -->

        <respstmt></respStmt>

    </titleStmt>

    <publicationStmt>/<publicationStmt>

    <sourceDesc></sourceDesc>

</fileDesc>


Notice that this structure does not have an <editionStmt> in its <fileDesc>.


With the approach above the only distinction is implemented via comments, but there is not structure for it. However, if we separate <respStmt> between <titleStmt> and <editionStmt>, adding the appropriate elements in <sourceDesc>, we can have a structure that represents the layers of responsibilities involved in the larger work. 


I was wondering if there is a reason for the conventional way, and if creating the suggested structure (adding an <editionStmt> and separating <respStmt>s) would cause more problems than do good.


Thank you,

Tracey


Tracey El Hajj
PhD Candidate | English
Junior Programmer | MoEML
Tutor | CAC
University of Victoria

Please consider the environment before printing this email

From: TEI (Text Encoding Initiative) public discussion list <[hidden email]> on behalf of Tracey El Hajj <[hidden email]>
Sent: Wednesday, June 27, 2018 3:01 PM
To: [hidden email]
Subject: <respStmt> in <titleStmt> Vs. <editionStmt>
 

Hi all,


In the <teiHeader> we have various options to include <respStmt>s. It is conventional that all <respStmt>s go in <titleStmt>, but when is it better to include them in <editionStmt> instead?


​Thanks,

Tracey​


Tracey El Hajj
PhD Candidate | English
Junior Programmer | MoEML
Tutor | CAC
University of Victoria

Please consider the environment before printing this email
Reply | Threaded
Open this post in threaded view
|

Re: <respStmt> in <titleStmt> Vs. <editionStmt>

Daniel Johnson
Hello Tracey,

If I understand you correctly, you are looking to attribute credit to the creators involved in the original source book (manuscript, papyrus, whatever), as well as to the creators involved in the new digital edition. If so, my understanding is this: <titleStmt> applies directly to the digital edition, while <sourceDesc> applies directly to the original source. 

So if you were encoding Romeo and Juliet, you might have a <respStmt> for yourself as editor of the digital edition under the <titleStmt>, and then you'd have an <author> for Shakespeare and <respStmt> for John Heminges and Henry Condell under <sourceDesc>. Does that make sense?

Now, if you were creating an edition of Romeo and Juliet based on another digital edition that is itself based on the 17th century First Folio, things get a little trickier, but I believe you'd put bibiographic information (including <respStmt> elements) for both the physical book and the first digital edition under <sourceDesc>, since these are both sources for your current digital edition. And, as before, you'd put a <respStmt> for yourself under <titleStmt>, along with an appropriate title: "The Very New and Improved Digital Romeo and Juliet".

Others, please correct me if I'm wrong.

Best,
Dan



On Thu, Jun 28, 2018 at 1:58 PM Tracey El Hajj <[hidden email]> wrote:

​With regards to the previous question:


When we are dealing with primary sources, we are looking at various options for encoding responsibilities. The first issue that I am looking at is a structural distinction between the original source's credits and the digital edition's (ours), which is rarely a 1st generation digital edition. 


The conventional way is to add <respStmt> in <fileDesc> <titleStmt>, commenting out the difference.

For instance, when assigning <respStmt> for the original work, we add a comment as such: <!!-- Primary respStmt belonging to the text -->. When encoding information about the digital edition, the following comment can be an example: <!-- Modern contributors, encoders, and transcribers -->.


<fileDesc>

    <titleStmt>

        <title></title>

        <!!-- Primary respStmt belonging to the text -->

        <respStmt></respStmt>

        <!-- Modern contributors, encoders, and transcribers -->

        <respstmt></respStmt>

    </titleStmt>

    <publicationStmt>/<publicationStmt>

    <sourceDesc></sourceDesc>

</fileDesc>


Notice that this structure does not have an <editionStmt> in its <fileDesc>.


With the approach above the only distinction is implemented via comments, but there is not structure for it. However, if we separate <respStmt> between <titleStmt> and <editionStmt>, adding the appropriate elements in <sourceDesc>, we can have a structure that represents the layers of responsibilities involved in the larger work. 


I was wondering if there is a reason for the conventional way, and if creating the suggested structure (adding an <editionStmt> and separating <respStmt>s) would cause more problems than do good.


Thank you,

Tracey


Tracey El Hajj
PhD Candidate | English
Junior Programmer | MoEML
Tutor | CAC
University of Victoria

Please consider the environment before printing this email

From: TEI (Text Encoding Initiative) public discussion list <[hidden email]> on behalf of Tracey El Hajj <[hidden email]>
Sent: Wednesday, June 27, 2018 3:01 PM
To: [hidden email]
Subject: <respStmt> in <titleStmt> Vs. <editionStmt>
 

Hi all,


In the <teiHeader> we have various options to include <respStmt>s. It is conventional that all <respStmt>s go in <titleStmt>, but when is it better to include them in <editionStmt> instead?


​Thanks,

Tracey​


Tracey El Hajj
PhD Candidate | English
Junior Programmer | MoEML
Tutor | CAC
University of Victoria

Please consider the environment before printing this email


--
Daniel Johnson, Ph.D.
English and Digital Humanities Librarian
Navari Family Center for Digital Scholarship, Hesburgh Libraries

University of Notre Dame
250C Hesburgh Library
Notre Dame, IN 46556
o: 574-631-3457



Reply | Threaded
Open this post in threaded view
|

Re: Textual Communities Launch

Stuart A. Yeates
In reply to this post by Robinson, Peter
I'm getting "textualcommunitessandbox.org’s server IP address could not be found." errors when trying to access https://textualcommunitessandbox.org/

https://textualcommunities.org/app/ looks fun though.

cheers
stuart

--
...let us be heard from red core to black sky

On 29 June 2018 at 04:35, Robinson, Peter <[hidden email]> wrote:
We are pleased to announce today the full public release of Textual Communities. Textual Communities is an environment for the collaborative online creation of scholarly editions.

There are two public versions of Textual Communities:

·      The production version, https://textualcommunities.org

·      The sandbox version, https://textualcommunitessandbox.org

You can create your own account on the sandbox version, and experiment with it.

Textual Communities has the following distinctive features:
·      It is not an adaptation of any other system, but is built anew from the ground up;

·      It understands text as a collection of leaves distributed across a document tree and an entity tree. Accordingly, it can both present text page by page (or line by line), as parts of a document tree, and it can present text entity by entity, as a hierarchy of acts of eommunication  (hence, line 1 of the General Prologue of the Canterbury Tales), as parts of an entity tree;

·      It offers powerful collation tools, CollateX and the Collation Editor, permitting precise tailoring of the collation of any entity in muliple documents;

·      It includes tools for managing collaboration: to invite, supervise and monitor multiple collaborators;

·      It includes an IIIF image server, and can create editiable documents from IIIF manifests;

·      It provides an API giving access to all materials through URI resource descriptors.

The documentation at https://wiki.usask.ca/display/TC/Textual+Communities offers a “Getting Started” guide, and various other documents.

We are grateful for the support of the Canada Foundation for Innovation, the Social Sciences and Humanities Research Council of Canada, and the University of Saskatchewan.


The Textual Communities Team, email [hidden email]

ADHO conference 2018,  Mexico City, 28 June 2018.


The text of the talk presenting Textual Communities at the ADHO conference is available at https://wiki.usask.ca/display/TC/Creating+and+Implementing+an+Ontology+of+Documents+and+Texts


Reply | Threaded
Open this post in threaded view
|

Re: <respStmt> in <titleStmt> Vs. <editionStmt>

Tracey El Hajj
In reply to this post by Daniel Johnson

Thank you, Dan. This is helpful, and it does make sense. 


​​When do you think we would use the <editionStmt> though?


Thanks,

Tracey


Tracey El Hajj
PhD Candidate | English
Junior Programmer | MoEML
Tutor | CAC
University of Victoria

Please consider the environment before printing this email

From: Daniel Johnson <[hidden email]>
Sent: Thursday, June 28, 2018 12:24 PM
To: Tracey El Hajj
Cc: [hidden email]
Subject: Re: <respStmt> in <titleStmt> Vs. <editionStmt>
 
Hello Tracey,

If I understand you correctly, you are looking to attribute credit to the creators involved in the original source book (manuscript, papyrus, whatever), as well as to the creators involved in the new digital edition. If so, my understanding is this: <titleStmt> applies directly to the digital edition, while <sourceDesc> applies directly to the original source. 

So if you were encoding Romeo and Juliet, you might have a <respStmt> for yourself as editor of the digital edition under the <titleStmt>, and then you'd have an <author> for Shakespeare and <respStmt> for John Heminges and Henry Condell under <sourceDesc>. Does that make sense?

Now, if you were creating an edition of Romeo and Juliet based on another digital edition that is itself based on the 17th century First Folio, things get a little trickier, but I believe you'd put bibiographic information (including <respStmt> elements) for both the physical book and the first digital edition under <sourceDesc>, since these are both sources for your current digital edition. And, as before, you'd put a <respStmt> for yourself under <titleStmt>, along with an appropriate title: "The Very New and Improved Digital Romeo and Juliet".

Others, please correct me if I'm wrong.

Best,
Dan



On Thu, Jun 28, 2018 at 1:58 PM Tracey El Hajj <[hidden email]> wrote:

​With regards to the previous question:


When we are dealing with primary sources, we are looking at various options for encoding responsibilities. The first issue that I am looking at is a structural distinction between the original source's credits and the digital edition's (ours), which is rarely a 1st generation digital edition. 


The conventional way is to add <respStmt> in <fileDesc> <titleStmt>, commenting out the difference.

For instance, when assigning <respStmt> for the original work, we add a comment as such: <!!-- Primary respStmt belonging to the text -->. When encoding information about the digital edition, the following comment can be an example: <!-- Modern contributors, encoders, and transcribers -->.


<fileDesc>

    <titleStmt>

        <title></title>

        <!!-- Primary respStmt belonging to the text -->

        <respStmt></respStmt>

        <!-- Modern contributors, encoders, and transcribers -->

        <respstmt></respStmt>

    </titleStmt>

    <publicationStmt>/<publicationStmt>

    <sourceDesc></sourceDesc>

</fileDesc>


Notice that this structure does not have an <editionStmt> in its <fileDesc>.


With the approach above the only distinction is implemented via comments, but there is not structure for it. However, if we separate <respStmt> between <titleStmt> and <editionStmt>, adding the appropriate elements in <sourceDesc>, we can have a structure that represents the layers of responsibilities involved in the larger work. 


I was wondering if there is a reason for the conventional way, and if creating the suggested structure (adding an <editionStmt> and separating <respStmt>s) would cause more problems than do good.


Thank you,

Tracey


Tracey El Hajj
PhD Candidate | English
Junior Programmer | MoEML
Tutor | CAC
University of Victoria

Please consider the environment before printing this email

From: TEI (Text Encoding Initiative) public discussion list <[hidden email]> on behalf of Tracey El Hajj <[hidden email]>
Sent: Wednesday, June 27, 2018 3:01 PM
To: [hidden email]
Subject: <respStmt> in <titleStmt> Vs. <editionStmt>
 

Hi all,


In the <teiHeader> we have various options to include <respStmt>s. It is conventional that all <respStmt>s go in <titleStmt>, but when is it better to include them in <editionStmt> instead?


​Thanks,

Tracey​


Tracey El Hajj
PhD Candidate | English
Junior Programmer | MoEML
Tutor | CAC
University of Victoria

Please consider the environment before printing this email


--
Daniel Johnson, Ph.D.
English and Digital Humanities Librarian
Navari Family Center for Digital Scholarship, Hesburgh Libraries

University of Notre Dame
250C Hesburgh Library
Notre Dame, IN 46556
o: 574-631-3457



Reply | Threaded
Open this post in threaded view
|

Re: Textual Communities Launch

Paul Schaffner
In reply to this post by Stuart A. Yeates
The URL as typed is just missing the second -i- in 'communities', as you've
doubtless seen.

Importing an XML doc seems to assume TEI as the schema; i.e., it
allows import of TEI documents, not of 'XML documents' per se.
Or have I missed something?

pfs

On Thu, Jun 28, 2018, at 16:12, Stuart A. Yeates wrote:

> I'm getting "textualcommunitessandbox.org’s server IP address could not be
> found." errors when trying to access https://textualcommunitessandbox.org/
>
> https://textualcommunities.org/app/ looks fun though.
>
> cheers
> stuart
>
> --
> ...let us be heard from red core to black sky
>
> On 29 June 2018 at 04:35, Robinson, Peter <[hidden email]> wrote:
>
> > We are pleased to announce today the full public release of Textual
> > Communities. Textual Communities is an environment for the collaborative
> > online creation of scholarly editions.
> >
> > There are two public versions of Textual Communities:
> >
> > ·      The production version, https://textualcommunities.org
> >
> > ·      The sandbox version, https://textualcommunitessandbox.org
> >
> > You can create your own account on the sandbox version, and experiment
> > with it.
> >
> > Textual Communities has the following distinctive features:
> > ·      It is not an adaptation of any other system, but is built anew from
> > the ground up;
> >
> > ·      It understands text as a collection of leaves distributed across a
> > document tree and an entity tree. Accordingly, it can both present text
> > page by page (or line by line), as parts of a document tree, and it can
> > present text entity by entity, as a hierarchy of acts of eommunication
> > (hence, line 1 of the General Prologue of the Canterbury Tales), as parts
> > of an entity tree;
> >
> > ·      It offers powerful collation tools, CollateX and the Collation
> > Editor, permitting precise tailoring of the collation of any entity in
> > muliple documents;
> >
> > ·      It includes tools for managing collaboration: to invite, supervise
> > and monitor multiple collaborators;
> >
> > ·      It includes an IIIF image server, and can create editiable
> > documents from IIIF manifests;
> >
> > ·      It provides an API giving access to all materials through URI
> > resource descriptors.
> >
> > The documentation at https://wiki.usask.ca/display/TC/Textual+Communities
> > offers a “Getting Started” guide, and various other documents.
> >
> > We are grateful for the support of the Canada Foundation for Innovation,
> > the Social Sciences and Humanities Research Council of Canada, and the
> > University of Saskatchewan.
> >
> >
> > The Textual Communities Team, email [hidden email]
> >
> > ADHO conference 2018,  Mexico City, 28 June 2018.
> >
> >
> > The text of the talk presenting Textual Communities at the ADHO conference
> > is available at https://wiki.usask.ca/display/
> > TC/Creating+and+Implementing+an+Ontology+of+Documents+and+Texts
> >
> >


--
Paul Schaffner  Digital Content & Collections
University of Michigan Libraries
[hidden email] | http://www.umich.edu/~pfs/
Reply | Threaded
Open this post in threaded view
|

Re: <respStmt> in <titleStmt> Vs. <editionStmt>

Daniel Johnson
In reply to this post by Tracey El Hajj
No problem, Tracey. I'd like to hear a bit more about <editionStmt> from others, too. It seems to me that <editionStmt> is commonly used to refer to the current "edition" of the digital edition you are creating, but defining an edition can prove tricky. So, you might have revisions recorded in the <revisionDesc> which are not significant enough to be considered a new edition.

For example, check out these samples from the Whitman Archive (https://whitmanarchive.org/manuscripts/tei/duk.00027.xml) and the Collected Letters of Robert Southey (http://www.rc.umd.edu/sites/default/files/imported/editions/southey_letters/XML/letterEEd.26.1.xml). Both record only a date in <editionStmt>, and in the case of the Whitman file, according to the evidence of <revisionDesc>, only the major change from P4 to P5 constituted a new "edition" of this digital work, even though there were minor changes several times in the years following.

To use a software analogy, it appears that these projects use an <editionStmt> to mark the date of change from, say, Windows XP to Windows 7, but they record smaller updates to the current Window operating system in the <revisionDesc>.

Best,
Dan



On Thu, Jun 28, 2018 at 4:13 PM Tracey El Hajj <[hidden email]> wrote:

Thank you, Dan. This is helpful, and it does make sense. 


​​When do you think we would use the <editionStmt> though?


Thanks,

Tracey


Tracey El Hajj
PhD Candidate | English
Junior Programmer | MoEML
Tutor | CAC
University of Victoria

Please consider the environment before printing this email

From: Daniel Johnson <[hidden email]>
Sent: Thursday, June 28, 2018 12:24 PM
To: Tracey El Hajj
Cc: [hidden email]
Subject: Re: <respStmt> in <titleStmt> Vs. <editionStmt>
 
Hello Tracey,

If I understand you correctly, you are looking to attribute credit to the creators involved in the original source book (manuscript, papyrus, whatever), as well as to the creators involved in the new digital edition. If so, my understanding is this: <titleStmt> applies directly to the digital edition, while <sourceDesc> applies directly to the original source. 

So if you were encoding Romeo and Juliet, you might have a <respStmt> for yourself as editor of the digital edition under the <titleStmt>, and then you'd have an <author> for Shakespeare and <respStmt> for John Heminges and Henry Condell under <sourceDesc>. Does that make sense?

Now, if you were creating an edition of Romeo and Juliet based on another digital edition that is itself based on the 17th century First Folio, things get a little trickier, but I believe you'd put bibiographic information (including <respStmt> elements) for both the physical book and the first digital edition under <sourceDesc>, since these are both sources for your current digital edition. And, as before, you'd put a <respStmt> for yourself under <titleStmt>, along with an appropriate title: "The Very New and Improved Digital Romeo and Juliet".

Others, please correct me if I'm wrong.

Best,
Dan



On Thu, Jun 28, 2018 at 1:58 PM Tracey El Hajj <[hidden email]> wrote:

​With regards to the previous question:


When we are dealing with primary sources, we are looking at various options for encoding responsibilities. The first issue that I am looking at is a structural distinction between the original source's credits and the digital edition's (ours), which is rarely a 1st generation digital edition. 


The conventional way is to add <respStmt> in <fileDesc> <titleStmt>, commenting out the difference.

For instance, when assigning <respStmt> for the original work, we add a comment as such: <!!-- Primary respStmt belonging to the text -->. When encoding information about the digital edition, the following comment can be an example: <!-- Modern contributors, encoders, and transcribers -->.


<fileDesc>

    <titleStmt>

        <title></title>

        <!!-- Primary respStmt belonging to the text -->

        <respStmt></respStmt>

        <!-- Modern contributors, encoders, and transcribers -->

        <respstmt></respStmt>

    </titleStmt>

    <publicationStmt>/<publicationStmt>

    <sourceDesc></sourceDesc>

</fileDesc>


Notice that this structure does not have an <editionStmt> in its <fileDesc>.


With the approach above the only distinction is implemented via comments, but there is not structure for it. However, if we separate <respStmt> between <titleStmt> and <editionStmt>, adding the appropriate elements in <sourceDesc>, we can have a structure that represents the layers of responsibilities involved in the larger work. 


I was wondering if there is a reason for the conventional way, and if creating the suggested structure (adding an <editionStmt> and separating <respStmt>s) would cause more problems than do good.


Thank you,

Tracey


Tracey El Hajj
PhD Candidate | English
Junior Programmer | MoEML
Tutor | CAC
University of Victoria

Please consider the environment before printing this email

From: TEI (Text Encoding Initiative) public discussion list <[hidden email]> on behalf of Tracey El Hajj <[hidden email]>
Sent: Wednesday, June 27, 2018 3:01 PM
To: [hidden email]
Subject: <respStmt> in <titleStmt> Vs. <editionStmt>
 

Hi all,


In the <teiHeader> we have various options to include <respStmt>s. It is conventional that all <respStmt>s go in <titleStmt>, but when is it better to include them in <editionStmt> instead?


​Thanks,

Tracey​


Tracey El Hajj
PhD Candidate | English
Junior Programmer | MoEML
Tutor | CAC
University of Victoria

Please consider the environment before printing this email


--
Daniel Johnson, Ph.D.
English and Digital Humanities Librarian
Navari Family Center for Digital Scholarship, Hesburgh Libraries

University of Notre Dame
250C Hesburgh Library
Notre Dame, IN 46556
o: 574-631-3457





--
Daniel Johnson, Ph.D.
English and Digital Humanities Librarian
Navari Family Center for Digital Scholarship, Hesburgh Libraries

University of Notre Dame
250C Hesburgh Library
Notre Dame, IN 46556
o: 574-631-3457



Reply | Threaded
Open this post in threaded view
|

Re: <respStmt> in <titleStmt> Vs. <editionStmt>

Tracey El Hajj

Thank you, Dan.


I agree with you, defining an edition can be tricky. I think what we would consider to be an edition is indeed the creation of a digital edition that is substantially different from what we have (transcription differences, etc.). I am also interested in what others think about that.


For us, we are looking at <editionStmt> as a place to record information about the particular edition at hand, especially <respStmt>s. <changes>s should be recorded in <revisionsDesc>.


Best,

Tracey


Tracey El Hajj
PhD Candidate | English
Junior Programmer | MoEML
Tutor | CAC
University of Victoria

Please consider the environment before printing this email

From: Daniel Johnson <[hidden email]>
Sent: Thursday, June 28, 2018 2:39 PM
To: Tracey El Hajj
Cc: [hidden email]
Subject: Re: <respStmt> in <titleStmt> Vs. <editionStmt>
 
No problem, Tracey. I'd like to hear a bit more about <editionStmt> from others, too. It seems to me that <editionStmt> is commonly used to refer to the current "edition" of the digital edition you are creating, but defining an edition can prove tricky. So, you might have revisions recorded in the <revisionDesc> which are not significant enough to be considered a new edition.

For example, check out these samples from the Whitman Archive (https://whitmanarchive.org/manuscripts/tei/duk.00027.xml) and the Collected Letters of Robert Southey (http://www.rc.umd.edu/sites/default/files/imported/editions/southey_letters/XML/letterEEd.26.1.xml). Both record only a date in <editionStmt>, and in the case of the Whitman file, according to the evidence of <revisionDesc>, only the major change from P4 to P5 constituted a new "edition" of this digital work, even though there were minor changes several times in the years following.

To use a software analogy, it appears that these projects use an <editionStmt> to mark the date of change from, say, Windows XP to Windows 7, but they record smaller updates to the current Window operating system in the <revisionDesc>.

Best,
Dan



On Thu, Jun 28, 2018 at 4:13 PM Tracey El Hajj <[hidden email]> wrote:

Thank you, Dan. This is helpful, and it does make sense. 


​​When do you think we would use the <editionStmt> though?


Thanks,

Tracey


Tracey El Hajj
PhD Candidate | English
Junior Programmer | MoEML
Tutor | CAC
University of Victoria

Please consider the environment before printing this email

From: Daniel Johnson <[hidden email]>
Sent: Thursday, June 28, 2018 12:24 PM
To: Tracey El Hajj
Cc: [hidden email]
Subject: Re: <respStmt> in <titleStmt> Vs. <editionStmt>
 
Hello Tracey,

If I understand you correctly, you are looking to attribute credit to the creators involved in the original source book (manuscript, papyrus, whatever), as well as to the creators involved in the new digital edition. If so, my understanding is this: <titleStmt> applies directly to the digital edition, while <sourceDesc> applies directly to the original source. 

So if you were encoding Romeo and Juliet, you might have a <respStmt> for yourself as editor of the digital edition under the <titleStmt>, and then you'd have an <author> for Shakespeare and <respStmt> for John Heminges and Henry Condell under <sourceDesc>. Does that make sense?

Now, if you were creating an edition of Romeo and Juliet based on another digital edition that is itself based on the 17th century First Folio, things get a little trickier, but I believe you'd put bibiographic information (including <respStmt> elements) for both the physical book and the first digital edition under <sourceDesc>, since these are both sources for your current digital edition. And, as before, you'd put a <respStmt> for yourself under <titleStmt>, along with an appropriate title: "The Very New and Improved Digital Romeo and Juliet".

Others, please correct me if I'm wrong.

Best,
Dan



On Thu, Jun 28, 2018 at 1:58 PM Tracey El Hajj <[hidden email]> wrote:

​With regards to the previous question:


When we are dealing with primary sources, we are looking at various options for encoding responsibilities. The first issue that I am looking at is a structural distinction between the original source's credits and the digital edition's (ours), which is rarely a 1st generation digital edition. 


The conventional way is to add <respStmt> in <fileDesc> <titleStmt>, commenting out the difference.

For instance, when assigning <respStmt> for the original work, we add a comment as such: <!!-- Primary respStmt belonging to the text -->. When encoding information about the digital edition, the following comment can be an example: <!-- Modern contributors, encoders, and transcribers -->.


<fileDesc>

    <titleStmt>

        <title></title>

        <!!-- Primary respStmt belonging to the text -->

        <respStmt></respStmt>

        <!-- Modern contributors, encoders, and transcribers -->

        <respstmt></respStmt>

    </titleStmt>

    <publicationStmt>/<publicationStmt>

    <sourceDesc></sourceDesc>

</fileDesc>


Notice that this structure does not have an <editionStmt> in its <fileDesc>.


With the approach above the only distinction is implemented via comments, but there is not structure for it. However, if we separate <respStmt> between <titleStmt> and <editionStmt>, adding the appropriate elements in <sourceDesc>, we can have a structure that represents the layers of responsibilities involved in the larger work. 


I was wondering if there is a reason for the conventional way, and if creating the suggested structure (adding an <editionStmt> and separating <respStmt>s) would cause more problems than do good.


Thank you,

Tracey


Tracey El Hajj
PhD Candidate | English
Junior Programmer | MoEML
Tutor | CAC
University of Victoria

Please consider the environment before printing this email

From: TEI (Text Encoding Initiative) public discussion list <[hidden email]> on behalf of Tracey El Hajj <[hidden email]>
Sent: Wednesday, June 27, 2018 3:01 PM
To: [hidden email]
Subject: <respStmt> in <titleStmt> Vs. <editionStmt>
 

Hi all,


In the <teiHeader> we have various options to include <respStmt>s. It is conventional that all <respStmt>s go in <titleStmt>, but when is it better to include them in <editionStmt> instead?


​Thanks,

Tracey​


Tracey El Hajj
PhD Candidate | English
Junior Programmer | MoEML
Tutor | CAC
University of Victoria

Please consider the environment before printing this email


--
Daniel Johnson, Ph.D.
English and Digital Humanities Librarian
Navari Family Center for Digital Scholarship, Hesburgh Libraries

University of Notre Dame
250C Hesburgh Library
Notre Dame, IN 46556
o: 574-631-3457





--
Daniel Johnson, Ph.D.
English and Digital Humanities Librarian
Navari Family Center for Digital Scholarship, Hesburgh Libraries

University of Notre Dame
250C Hesburgh Library
Notre Dame, IN 46556
o: 574-631-3457