- ab
- abbr
- acquisition
- add
- additional
- additions
- antiphon
- app
- bibl
- binding
- bindingDesc
- catDesc
- category
- cb
- Certainty
- change
- choice
- cit
- citedRange
- collation
- collection
- colophon
- condition
- country
- creation
- custEvent
- date
- decoDesc
- decoNote
- del
- depth
- desc
- dim
- dimensions
- div
- editor
- ex
- expan
- explicit
- facsimile
- faith
- filiation
- foliation
- foreign
- gap
- geo
- graphic
- keywords
- handDesc
- handNote
- handShift
- height
- hi
- history
- idno
- incipit
- item
- l
- language
- layout
- layoutDesc
- lb
- lem
- list
- listApp
- listBibl
- listPerson
- listRelation
- listWit
- locus
- material
- measure
- msContents
- msDesc
- msIdentifier
- msItem
- msFrag
- msPart
- nationality
- notatedMusic
- note
- objectDesc
- occupation
- orig
- origDate
- origin
- origPlace
- p
- pb
- persName
- person
- personGrp
- physDesc
- place
- placeName
- provenance
- ptr
- q
- quote
- rdg
- ref
- region
- relation
- repository
- roleName
- rubric
- seal
- sealDesc
- seg
- settlement
- signatures
- source
- space
- subst
- summary
- supportDesc
- supplied
- surrogates
- TEI
- term
- textLang
- title
- unclear
- watermark
- width
- witness
- active
- ana
- assertedValue
- atLeast
- atMost
- cRef
- calendar
- cause
- cert
- color
- columns
- contemporary
- corresp
- defective
- dur
- evidence
- facs
- form
- from
- hand
- href
- ident
- key
- n
- name
- new
- notAfter
- notAfter-custom
- notBefore
- notBefore-custom
- part
- passive
- pastedown
- place
- reason
- ref
- rend
- rendition
- resp
- role
- sameAs
- script
- source
- subtype
- target
- to
- type
- unit
- url
- value
- when
- when-custom
- who
- wit
- writtenLines
- xml:base
- xml:id
- xml:lang
- @source
- Additional
- Additions and Varia
- Aligning transliteration and morphological annotations with Alpheios Alignment Tool
- Art Themes
- Attribution of single statements
- Authority files (keywords)
- Bibliographic References
- Binding Description
- Canonicalized TEI
- Catalogue Workflow
- Collation
- Colophons, Titles and Supplications
- Contributing sets of images to the research environment
- Contributing to the research environment
- Corpora
- Create New Entry
- Create a new file, delete existing, deal with doublets
- Critical Apparatus
- Critical Edition Workflow
- Dates
- Decoration Description
- Definition of Works, Textparts and Narrative Units
- Documentary Texts
- Dubious spelling
- Editing the Schema
- Editing these Guidelines
- Editions in Work Records
- Entities ID structure
- Event
- Figures and Links to Images
- General
- General Structure of Work Records
- Groups
- Hands Description
- History
- Identifiers Structure
- Images
- Images of Manuscripts for editions
- Inscriptions
- Keywords
- La Syntaxe du Codex
- Language
- Layout
- Letters
- Linking from Wikidata to the research environment
- Manuscript Contents
- Manuscript Description
- Manuscript Physical Description
- Manuscripts
- Named Entities
- Narrative Units
- Object Description
- Person
- Place or Repository
- Places
- References
- References to a text and its structure
- Referencing parts of the manuscript
- Relations
- Relative Location
- Repositories
- Revisions
- Roles and roleNames
- Scrolls
- Seals Description
- Setup
- Some useful how-to for personal workspace set up
- Spaces
- Stand-off annotations with Hypothes.is
- Standardisation of transcription from Encyclopaedia Aethiopica
- State and Certainty
- Statements about persons
- Structure
- Summary on the Use of @ref and @corresp
- TEI
- Taxonomy
- Team IDs
- Text Encoding
- Training Materials
- Transcriptions with Transkribus
- Transformation
- Transliteration Principles
- Users
- Using Xinclude
- Validation process
- Workflow
- Works
- Works Description
- Zotero Bibliography Guidelines
- titleStmt of Manuscript Records
Revisions
It is very important to add a <change>
↗ in the <revisionDesc>
↗ element of
the <teiHeader>
↗ at the end of each section of work of improvement of a record. In
the attribute @who
enter your ID, in the
@when
enter the date of the change, in the format YYYY-MM-DD. You can use
code templates in Oxygen to do this. There is a set ready for you which also includes
this. Inside the element, briefly describe the changes you have made.
<revisionDesc>
<change when="2010-12-04">registered</change>
<change who="DN" when="2015-09-11">last edited</change>
<change who="PL" when="2016-03-10">transformed from mycore to TEI P5</change>
</revisionDesc>
Example 1
Best thing would be to do this every time you are not simply adding a comma.
The file should be submitted for revision to a second author taking care of describing, according to the guidelines, the event.
-
Cataloguer will enter a
<change>
↗ with content Submitted for review, once she is finished. -
Reviewer will add a
<change>
↗ with content Reviewed and Corrected, -
General editor will enter a
<change>
↗ with value Approved
If you change, for example, an ID in many files you don't want to go back to each and
add a <change>
↗, but in that case there is also the GIT commit message which will
help. Please use it! There is no need to commit immediately every small change made,
thus multiplying them and their titles and descriptions, but when we do commit something
(after checking, validating, checking again and being very sure), it is extremely
important to give a proper title and any relevant information helping to investigate the
change in the future.
If one has to revert a commit of 40 files and all the commit says is "update" and there is no change element, anyone looking into the commit which caused the issue is forced to do hand comparing on each commit to find out which one might contain the mistake and then check each file by hand, i.e. the whole workflow and file versioning is rather vain.
The <revisionDesc>
↗ in the files and the commits to GIT (titles and descriptions)
are our way to keep track of the work easily and they become more and more important as
we proceed, so please let us not skip these steps, they are not time-consuming and they
are of great importance in the short and long term.
In <change>
↗, please describe what you have changed in the file, e.g. "added
msItems and transcription of divs".
In the commit title, try to provide a descriptive title which will make it as easy as possible to know at a glance what you have committed there. so, "added IDs" is way much better of "minor correction" (and shorter!) "added perName elements" is better than "changed something".
You can use the commit description to link and refer to issues, if the explanation of what you have done is there. The issue will also receive that information and provide a link to the commit.
Revisions of this page
- Pietro Maria Liuzzo on 2018-04-30: first version of guidelines from Wiki