- there are two pages with id layoutDesc!
- Additions and Varia
- Art Themes
- Attribution of single statements
- Authority files (keywords)
- Bibliographic References
- Binding Description
- Create New Entry
- Critical Apparatus
- 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
- General Structure of Work Records
- Hands Description
- Identifiers Structure
- Images of Manuscripts for editions
- Manuscript Contents
- Manuscript Description
- Manuscript Physical Description
- Named Entities
- Narrative Units
- Object Description
- Place or Repository
- Relative Location
- Roles and roleNames
- Seals Description
- Some useful how-to for personal workspace set up
- Stand-off annotations with Hypothes.is
- Standardisation of transcription from Encyclopaedia Aethiopica
- State and Certainty
- Statements about persons
- Summary on the Use of @ref and @corresp
- Team IDs
- Text Encoding
- Transliteration Principles
- Validation process
- Works Description
- Zotero Bibliography Guidelines
- titleStmt of Manuscript Records
Editing these Guidelines
How it works
These guidelines are fed by a Github webhook pushing into the web application at http://betamasaheft.eu/Guidelines/ data from the guidelines repository, the Beta maṣāḥǝft schema repository and the Beta maṣāḥǝft ontology (this is not via webhook).
If you edit and push (or make a pull request) to the above repos, the XML files will be sent to the application and go live so that you can see them, search, browse, read, etc.
Editing the XML
You can use any editor you like to edit the XML files. This page describes only the editing of the guidelines, for the editing of the schema see editing the Schema.
There is a Beta maṣāḥǝft Guidelines Schema which validates the files you are pushing to the app when editing the guidelines and will notify you if anything goes wrong. Actually, there are processing instructions in every single file that should allow your editor to validate your XML BEFORE you push it to the repo.
In principle, given that the information is displayed together, what is already specified in the schema should not need further clarification, so, e.g. there is no need to repeat a list of values for an attribute if this is in the schema.
Besides the schema folder (which is the Beta maṣāḥǝft Guidelines Schema), the guidelines folder contains subfolders for pages, elements, the table of contents (toc) and the user guide:
- Pages are descriptive pieces like this one, trying to explain how to encode something.
- Tables of Contents (toc) are simply lists, organizing pages in meaningful ways based on type of user, kind of task, etc.
- Elements describe one element: They link to the page of the respective element in the TEI guidelines, fetch from the Beta maṣāḥǝft schema any further specification and link back to all guideline pages mentioning this element.
We use the TEI Documentation Elements.
The application will use the
<body>↗ to identify the
pages and elements, so, please take care not to duplicate
@xml:ids if you are
creating a new page. The application will use the
<titleStmt>↗ as a label for that resource. This means that you can
have a page and an element called "person" but these will need two different
<div>↗ elements to structure the contents. These should have
@typewith level2 where the digit is a number from 2 to whatever the deepness of sections required is.
- A child
<head>↗ with the title of the subsection.
Links are encoded using
- You can enter in
@targetsimply the ID of any of the pages in the guidelines:
for the editing of the schema see editing the Schema
- You can add a
@typewith bm and your
@targetcan simply be the ID of any of the entities in Beta maṣāḥǝft. This is useful to link to examples:
special cases like BNFet45
- If you enter a URL, this will become an external link:
entering data in the Zotero Group Library.
Please always use
mark up respectively element names, tags, attributes names and values. You do
not need to type angle brackets and escape them or to add @ in front of every
attribute, this will be done during the visualization. For elements a link will
also be given to the page for that element.
To add examples of XML markup, use the
<egXML>↗ element, always with its
<egXML xmlns="http://www.tei-c.org/ns/Examples">↗. This
allows the validation to skip the contents (i.e. do not add again the TEI
namespace in the examples).
Good practice should be always used in providing examples, which should not be made up but reflect the encoding in a currently existing file. It is also good practice to add a
<ref>↗ with a link to the file where this is to be found.
This page is referred to in the following pages
Revisions of this page
- Pietro Maria Liuzzo on 2018-04-30: first version of guidelines from Wiki
- Dorothea Reule on 2018-05-14: Edited and added examples