Warning: Illegal string offset 'Poetry' in /users/hoffmann/www/lml/ea_inc.php on line 6

Warning: Illegal string offset 'Prose' in /users/hoffmann/www/lml/ea_inc.php on line 30

Warning: Illegal string offset 'Code' in /users/hoffmann/www/lml/ea_inc.php on line 122

Warning: Illegal string offset 'Block' in /users/hoffmann/www/lml/ea_inc.php on line 147

Warning: Illegal string offset 'Inline' in /users/hoffmann/www/lml/ea_inc.php on line 216

Warning: Illegal string offset 'Metadata' in /users/hoffmann/www/lml/ea_inc.php on line 317

Warning: Illegal string offset 'Conditional' in /users/hoffmann/www/lml/ea_inc.php on line 454

Warning: Illegal string offset 'Common' in /users/hoffmann/www/lml/ea_inc.php on line 477

Warning: Illegal string offset 'Archive' in /users/hoffmann/www/lml/ea_inc.php on line 542
<LML /> 2.0 - Metadata Markup Module

<LML /> 2.0 - Metadata Markup Module

specification

Author: Dr. O. Hoffmann (German web-page)

This module belongs to the Literature Markup Language Version 2.0

Changes

There are many new elements in LML 2.0 indicated in the element index with (v2).

Element-Index

Complete Element and Attribute Index

Metadata elements

Metadata is considered to be data about a document or document fragment. Corresponding to the higher level of abstraction of these data, some metadata are typically well separated from the fragment, they are about, the so called flow content, but the relation is unambiguously. Therefore separated metadata are typically presented additionally to the document itself, but not embedded inside 'normal' flow content of the document. For example such meta information is available on demand or in a different presentation area like a popup with a content menu or a specific meta information area of the user-agent. This happens for example for link elements in (X)HTML.

(X)HTML as an already older digital format does not provide convenient possibilities to provide much metadata identifiable as such and well separated from other flow content. Therefore metadata elements may appear within the other flow content area too due to the limitation of the used host language or the user-agents. Authors may use styling to simulate this functionality in such a case.

Additional to those separated metadata information - often due to the limitations by the format or the presentation as already mentioned - there is a longer tradition in providing meta information directly within the normal content flow, for example as a project navigation menu or an index, because this metadata is urgently required to get access to the meta information. This is possible too with some metadata elements, but the results may be plurivalent, if there is no unambiguous relation between the meta information and the content it is talking about.

The meta element is a container, where the meta information is always clearly separated from other flow content. Content of a meta element is not intended to flow within the content before and after it.

If there is no pointer to specify it differently, the meta information inside meta is about the parent element. Then the parent element is the target of the meta information. For other metadata elements if no pointer specifies it differently, the meta information is about the next parent literature, bq, respectively q or comment element, if there is none of these elements at all, it is about the document itself. With the RDF nomenclature the target is the subject of the meta information.

Direct children of the meta element are always considered as block elements. If other metadata elements than meta occur outside of the meta element, their appearance is indicated as (block) or (inline).

The semantic meanings of the metadata elements inside the meta element indicate the predicate within the RDF nomenclature. This can be done too with the attributes about, rel or rev or the related constructions with the elements rel or rev.

The content of the metadata elements or the content of the content attribute is the object within the RDF nomenclature. External (or embedded) objects can be specified with an attribute to reference content as the XLink:href. Another method is to use the attribute resource. Different from a usual hyperlink functionality functionality resource does not provide a direct access to the reference object, but if a URI is provided, the access should be available on demand.

If the element, such a metadata element is inside, only allows inline content, such a metadata element is considered to be inline. On the other hand, if the element allows both inline and block, but the other children of the element are consistently block (inline) elements, the metadata elements may be considered to be block (inline) too, however it is a much better approach, if the author puts already a fitting element around it to get a clean structure. The same rule applies for metadata elements being children of metadata elements not being direct children of the meta element. However authors should avoid such complicated situations of mixes of block and inline children in the same level in general and should structure always consistently. Due to the intentionally vague structure model of LML, authors can technically mix a lot of elements somehow, but they are recommended to provide a clear structure for better understandability.

meta

Description

Type: Meta (block)

A container for metadata or meta information about a document or document fragment. Any element can have meta element(s), even if not mentioned in the element definition. Exceptions are elements of the archive modul, those have a strictly defined content model, some of them do not allow directly further meta information about themselves. The meta element(s) should be before other children elements, maybe except title of the root element of the document. If title is provided outside the meta, it is recommended to place it before the meta element.

Content inside a meta element is always considered as meta information, presented typically not directly within the 'normal' progress or flow of presentation.

If not defined otherwise within the meta element, the meta element content provides information about its parent element.
If the meta is indicated to be about other content:
Part of the additional presentation of this content is the identification of the content the meta information belongs to. It is recommended, that the identification works in both directions, the meta information points to the target of the meta information, the target points back to the related meta information. For both are specific metadata elements provided.

meta is expected to contain structured information, this can be constructed with the same elements used to provide 'normal' flow content or it can be done with a specific language like RDF, but typically not both in one meta element.

meta will typically not contain another meta element as a direct child or in general typically a meta will not be the target of a meta. But there can be more than one meta element in one element, especially if the different meta elements provide alternative approaches for meta information about the same content or if the meta information is addressed to different fragments.

If a meta element anyway is the target of a meta element, this might be only done to provide unproblematic meta information about the target meta element itself. Cycling structures or self descriptions are strictly limited to basic information, else this may imply inconsistencies and contradictions due to the Gödel problem. This means, that self-contradictory constructions like 'this statement is wrong' are technically possible and an old fashioned joke, but not expected and meaningless as meta information.

Relations

title

Description

Type: Meta (block or inline)

The title of a complete piece of literature, often included in a literature element. In this case it is a block element with some prominent appearance. Within a citation it can indicate the title of a work, a part is quoted. For headings of chapters, sections and other fragments the related elements h and hs are used instead.

The title represents the complete work, therefore if chosen for an own work, it needs to be quite expressive and usable to identify the document if used for example as reference text in a citation.

If used as document title, the title element should be on top of the content of the literature element of the document respectively in the meta element applicable for the literature element of the document. If it is the title of the root literature element, the meta element should be always on top of the content of the root element to simplify the identification of the document title. If there are plurivalences, the topmost direct child title of the root element respectively the topmost title in the topmost direct child meta of the root element is used as document title, whatever comes first.

The document title is often used in a user-agent as a heading of the viewport, the content is presented in, therefore the place for this purpose is limited, anyway the title should be accessible completely in the presentation of the meta information. If the title is not inside a meta, it is presented with the content and if it is identified as document title, it will be often used as the heading of the viewport too. There is no need for authors to note it twice, but it is not wrong to use a h element too for the general presentation purpose. But user-agents will not consider a h element as heading for a viewport.

If title is used within a citation in a cite, for example together with the element creator, it is simple inline flow content. This means, that typically for visual presentation the size of the title is not changed as for headings, because the title is only referenced, but does not represent a heading in the current document.

Addition Version 2.0

If a title of a work in literature or meta consists of main and subtitles, it is possible to use h and hs within title to get the intended markup. If a title requires inline markup for example sub or sup within title, this is allowed as well. But else typically a title is kept simple and has no complex substructure. But if it has, title may contain flow content.
If title is used within the normal flow content for citation, it should not contain block elements like h and hs.

Relations

desc

Description

Type: Meta (block)

A container for a description inside the meta element for the target of the meta element. The content of the desc element can be structured with 'normal' flow elements.

Relations

bibcite (v2)

Description

Type: Meta (block)

This element is expected to contain bibliographic references for the work and is intended for references or identifiers or specific notations not covered by the element identifier.

Relations

cite

Description

Type: Meta (inline)

If some content from another author is quoted, it is required to provide information about the resource, work, project, book, web-page, whatever applies. This element is expected to contain or to reference this information. Often this will be a link to another resource or to a bibliography list item containing the related information. The cite may contain title and creator too.

Only if the author is the only known or citable source for example for a private communication quotation, the name of the author can be a useful solely content of the cite. It is either directly inside the q or bq element it is related or inside a meta element about a q or bq element or it points somehow to the quotation it is applicable for and the quotation points back to the cite to identify the relation vice versa.

It is possible too, that some other resource is not quoted word-by-word, it is only summarised, what is relevant for the current text. In such a case the cite can be expected outside of q, bq or meta too at the end of such a summary. In this case, if not specified otherwise the citation is related to the content provided by the direct parent of the cite element.

Relations

Samples for cite

conformsto (v2)

Description

Type: Meta (block)

This is intended for meta information about either fragments in other formats or for meta information about a host language, that has no version information. The content is a list of IRI/URIs, separated with whitespace, to the applicable specifications. In case of conflict later noted IRI/URIs are more important than earlier noted, but such a conflict should be avoided by careful selection. Additionally to the required namespace indication for the format in general, this is relevant, if there are different versions and profiles of a format to distinguish.

Usage with RDFa within a host language typically with property and content or resource or maybe a host language dependent linking mechanism within a metadata section of the format.

Especially important for 'HTML5' as a host language, because it has no version identifier.

More problematic is the case for styling documents written in CSS. In such a case one has to point to the CSS document using RDFa about. However, if a host language like XHTML has own linking elements to refer to styling documents instead of using the more general XML style-sheet-processing-instructions, it is possible to note property and resource directly for this linking element.

Relations

coverage (v2)

Description

Type: Meta (block)

This element is expected to contain coverage information for the work. Expected content is covspatial or covtime or covtimeh to indicate spatial, geographic and temporal relations for the content of the work, in case it provides information about a specific area or time. There may be other coverage information as well, those are expected to be in elements g.

Relations

covspatial (v2)

Description

Type: Meta (block)

This element is expected to contain spatial coverage information for the work. But there is no specific structure for this information defined. If required, some markup from a language about geography might be a good idea, but some prose content might be sufficient as well.

Relations

covtime (v2)

Description

Type: Meta (block)

This element is expected to contain temporal coverage information for the work. The content follows the same syntax as created.

Relations

covtimeh (v2)

Description

Type: Meta (block)

This element is expected to contain temporal coverage information for the work. The content follows the same syntax as createdh. The usage of covtime has precedence, if available.

created

Description

Type: Meta (inline)

The creation dates or time intervals of the related document or document fragment. If there is more than one date or interval, this element may contain a grouped list of dates or intervals using lg or list. Typically the list will start with the earliest date related to the document. Other orders can be indicated with a list type.

Another approach for more than one creation time period is to provide a list of created elements. Within a meta element there is no need for list grouping or another separation than whitespace, but especially if only used as role or property in another host language within normal text, it can be useful to add additional commata as separators.

If there is more than one applicable element created for one fragment with dates only with different accuracies, that with the highest accuracy can be used, if exactly one has to be chosen. If several different dates are applicable, they are assumed to indicate different versions or later updates.

A subset of the international standard ISO 8601:2004 for date and time is used to provide an understandable content.
For a date this looks like ±YYYY-MM-DDThh:mm:ss.fZ.
'-' and ':' within the string are separators.
± indicates an optional sign of the year, typically only '-' is used, if required. If it is missing, a '+' is implied.
YYYY are four digits for the years (more digits only if required and always in combination with the sign, for smaller year numbers one has to use leading zeros to get at least four digits), MM two digits for the month, DD two digits for the day.
'T' is a separator between the date and the following time with hh two digits for the hour, mm two digits for the month, ss.f the seconds with two digits before the optional fractional part of seconds, typically not required for literature, if not generated somehow automatically (leap seconds are possible too).
Z is an indicator for UTC, alternatively the time zone can be indicated with ±hh:mm. Either Z or the time zone should be present, if the T part is present.

If not required, parts after a separator including the separator itself can be skipped, for example:
2008
or
2008-10
or
2008-10-12
or
2008-10-12T12:30Z
or
2008-10-12T12:30:05.0234Z
or
2008-10-12T14:30:05.0234+02:00
or
2008-10-12T14:30+02:00

'/' is used to indicate a time interval: 2008-10-02/2008-10-12 means from the second to the twelfth of october 2008, the same as 2008-10-02/12 or 2008-10-02/10-12 .

It is explicitly discouraged to use plurivalent short forms or the basic format (almost without separators), because it is expected, that some literature survives long times, even if not originally intended.

If the (creation) time is not exactly known, this means especially not even the year, a preceding ~ can be used to indicate an estimated date, typically only the year or a range of years. There is no precisely predefined accuracy for this or the other notations. Without the ~ it can be assumed, that the accuracy is implicitly included, if only a date is given (no timezone), the accuracy is about one day. If date and time are given, the shortest time indication, for example minutes, indicate the accuracy implicitly. The event happened within the interval beginning with the indicated minute and ends before the next minute interval begins (includes the begin and excludes the end). The same applies for hours, seconds or fractional seconds.

A leading indicator ~ means typically an accuracy a few times lower than this, if combined with an hour as highest resolution level, this means a few hours around the given date and time. If provided for a year, this means a few years around the given specified year. Because there is no lower resolution than years, authors have to provide lower accuracies than about 10 years separately outside of the element with another notation or some additional prose.
Those accuracy discussion already indicates, that for a large amount of literature it is contra-productive or wrong to provide a high accuracy creation information, because it takes typically a longer time to produce some piece of literature, therefore it is wrong to note the creation time with an accuracy of a second or below and no interval. However, this can be possible or meaningful for automatically generated content.

Relations

createdh (v2)

Description

Type: Meta (block)

This corresponds to the element created, but only for such dates not describable as UTC or TAI. The reason can be, that the UTC is not known or especially for historical reasons not applicable. This is important, because UTC or TAI is pretty meaningless for older documents and not known or known dates are not transformable to UTC or after a transformation these dates are not meaningful for historians anymore. The attributes typeof or datatype should be noted to indicate the used calendar system.

creator

Description

Type: Meta (inline)

The names of the authors or editors of the related document or document fragment. If there is more than one author or editor, this element may contain a grouped list of names using lg or list. The order of authors is expected to be in such a way, that the main author is the first name in the list. The list type may indicate the order of author names, if required.
The author does not necessarily publish the document, therefore there is another element available, the publisher.

Another approach for more than one creator is to provide a list of creator elements. This can be necessary, if one wants to refine the task, contribution or relation of authors to the work, using the attribute type.
Within a meta element there is no need for list grouping or another separation than whitespace, but especially if only used as role or property in another host language within normal text, it can be useful to add additional commata as separators.

type (v2)

Description

Type: Attribute

type refines the meaning of the element due to the contribution or the relation of the creator or contributor to the work.

The value is either a code from the MARC list or a safe CURIE: '[' CURIE ']'

List with examples:

'aut'
Author, Coauthor
'art'
Artist (Graphics, Illustration)
'adp'
Adaptor, someone providing a new interpretation of a work or theme or reworks for a rendition in a new media
'ann'
A person who makes manuscript annotations on an item
'arr'
A person who reworks and arranges a work for presentation
'asn'
Associated Name
'aqt'
Author in quotations or text abstracts
'aft'
Author of the afterword, colophon, etc
'aud'
Author of a dialog
'aui'
Author of foreword, introduction, etc
'ant'
Bibliographic antecedent, responsible person or Organisation
'bjd'
Bookjacket, cover designer
'bkp'
Book designer
'ccp'
Conceptor, a person or organisation responsible for the original idea on which a work is based
'clb'
Collaborator
'cll'
Calligrapher
'cmm'
Commentator, author of interpretation
'cns'
Censor
'col'
Collector
'com'
Compiler, aggregation of sources, for example for an anthology
'crr'
Corrector
'cur'
Curator
'cwt'
Commentator for written text
'dis'
Dissertant, Author of a dissertation
'dsr'
Designer
'dte'
Dedicate, a person, family, or organisation to whom a resource is dedicated
'dto'
Dedicator, Author of the dedication
'dub'
Dubious author, a person or organisation to which authorship has been dubiously or incorrectly ascribed
'edc'
Editor of a compilation
'edt'
Editor
'exp'
Expert
'fac'
Facsimilist
'frg'
Forger, a person or organisation who makes or imitates something of value or importance, especially with the intent to defraud
'ill'
Illustrator
'ivr'
Interviewer, reporter
'lel'
Libelee, a person or organisation against whom a libel has been filed
'lil'
Libelant, a person or organisation who files a libel
'lyr'
Author of lyrics
'mrk'
Markup editor
'mdc'
Metadata contact
'mus'
Musician, musical contribution
'nrt'
Narrator
'oth'
Person with a function with no reserved code
'pbl'
Publisher
'pfr'
Proofreader, a person who corrects printed matter.
'pht'
Photographer
'prt'
Printer
'pro'
Producer
'pub'
Publisher
'red'
Redaktor
'res'
Researcher
'rev'
Reviewer, author of a recension
'spn'
Sponsor
'ths'
Thesis advisor
'trc'
Transcriber
'trl'
Translator
'wit'
Witness of an event

Relations

contributor

Description

Type: Meta (inline)

The names of contributors for the related document or document fragment. Coauthors with a direct contribution are to be noted within the element creator. Contributors are no direct authors or creators of the current digital work and contribute in another way to the document. If there is more than one contributor, this element may contain a grouped list of names using lg or list.

As for creator more than one contributor element can be used as well. This can be necessary, if one wants to refine the task, contribution or relation of authors to the work, using the attribute type.

type (v2)

Description

Type: Attribute

type refines the meaning of the element due to the contribution. See the same attribute for creator: type

Relations

distributor

Description

Type: Meta (inline)

The names of the persons, responsible for the distribution of the related document or document fragment. If there is more than one distributor, this element may contain a grouped list of names using lg or list. The order of distributors is expected to be in such a way, that the main distributor is the first name in the list. The list type may indicate the order of distributor names, if required.

Relations

editor

Description

Type: Meta (inline)

The names of the persons, responsible for the release of the related document or document fragment. If there is more than one editor, this element may contain a grouped list of names using lg or list. The order of editors is expected to be in such a way, that the main editor is the first name in the list. The list type may indicate the order of editor names, if required.

Relations

editions (v2)

Description

Type: Meta (block)

If there are previous editions or revisions of the document, it can be relevant to indicate the publication or creation dates for previous editions or revisions. This element is expected to contain related information, especially elements created, createdh, published, publishedh. Within this element the meaning is restricted to dates for previous editions, not the current. If available, other information about previous editions can be added as well. Concerning the order it is expected, that information about one edition consisting of more than one element is grouped together using an element g. The information is expected to be ordered, oldest editions first, the newest is the last entry.

Relations

  • TEI: revisionDesc

variants (v2)

Description

Type: Meta (block)

If there are other variants or versions of a work available with slightly different content for different purposes, not only previous editions, it can be relevant to provide information about such alternatives. This element is expected to contain related information, especially elements created, createdh, published, publishedh. Within this element the meaning is restricted to dates for alternative variants of the work, not for the current. If available, other information about alternative variants can be added as well. Concerning the order it is expected, that information about one edition consisting of more than one element is grouped together using an element g. The order of these information groups or alternative works has no defined meaning.

genre

Description

Type: Meta (block)

Indicates the genre, the document or document fragment belongs to. If more than one genre applies, the items are separated with whitespace.
Genres can be grouped together.
A group is indicated with parenthesis, '{' at the beginning, '}' at the end.
A group can contain other groups. A '!' before a group or item indicates a negation. With a negation it is possible to indicate not intended genre areas to avoid plurivalences.

Example:
'{erotic documentary} !{crime porn}' simply means, that it is a documentation about erotics, but there is not both crime and porn in it. '{erotic documentary} !crime !porn' what is the same as '{erotic documentary} {!crime !porn}' indicates too a documentation about erotics, but here it contains neither crime nor porn.

Another example:
'fashion forMen !heterosexual' is not exactly the same as 'fashion forMen homosexual', because there are bisexual and asexual men too. The second means, the reader can expect fashion for homosexual men.

Predefined values (simplified syntax for some words):

Some more predefined values specific for poetry:

Literature theme areas:

Because these lists are not exhaustive, they may be extended in the future. If an author wants to extend it with a currently not existing type, the value has to be a safe CURIE: '[' CURIE ']' pointing to a definition of the type or genre.

A classification system can be used too, for example PACS. Notations of such a system are included in such parenthesis: '()'. If available a CURIE for the classification scheme should be added too, locking like this: ('[' CURIE ']' 'classification code'). Such parenthesis within the classification code needs of course to be masked as other critical glyphs from XML too.

The predefined items can be translated for display in the preferred language of a user, the expected presentation is the untranslated item first followed by the translation in parenthesis.

Addition Version 2.0

Content might be intended for a specific age range of the audience, such information can be provided as well. Such information is always enclosed with '§'. Between there is a not negative number to indicate the age in years, typically a range 'from'/'to', including the given limits, for example '§10/19§'. An open upper limit can be indicated with '+': '§16+§'. As for other genre information a negation can be provided as well: '!§18/66§' means not intended for people between 18 and 66. Respectively '!§14+§': younger than 14, effectively the same as: '§0/13§'.

Relations

identifier

Description

Type: Meta (inline)

A permanent identifier for a document (fragment), like a URN, PURL, ISBN, DOI, UUID, EBI or another type of identifier. The main idea is, that such an identifier is unique for the document (fragment) and does not change sometimes for whatever reason. Once a document has stabilised somehow, it may get such an identifier. Updates and later versions may get another identifier. Alternatively the identifier for a current version may remain the same and if previous versions are provided too, they may get their own identifier. One document can have more than one identifier, but if it once has an identifier, this identifier will not get invalid anymore. If it is required to identify the type of identification, the attribute datatype can be used.
The content starts with an abbreviation of the identifier type, followed by ': ' and the identifier itself, for example:
'EBI: [Dr. Olaf Hoffmann|LML 2.0|1] [2015-05-18T21:12:37.003Z] [20|Ij8-q61-3PO-mio-8714]'

EBI (v2)

For independent authors it is often not trivial to get a unique identifier for free, even the almost randomly generated UUID is not really optimal for this, but the EBI has the capability to combine work intrinsic readable information and time dependent readable information with a random string to ensure practically perfectly a unique identifier for digital books or in more general for digital works.

An EBI consists of three blocks, each enclosed in square brackets '[]'.
These blocks succeed each other, optionally separated with whitespace between.

The first bracket contains characteristics from the author or publisher.
The second bracket contains time information.
The third bracket contains a random string.

In the first bracket are three entries.
Those a separated from each other with a '|'.
Each entry is a simple string, excluding '|' itself.
An encoding of the string with UTF-8 has to be possible.
The first entry is a name or nick name for the author, publisher or the institute, which created the work.
The second entry is the title of the work or an abbreviation for it.
The third entry is a number in decimal notation for the edition or version. Especially for series or collections it might be useful to use floating point numbers like 137.14 as well, not just integers.
If an entry is not intended, it is left empty, no whitespace. This ensures, that if a work has no title this can be distinguished from a work having whitespace as title.

The second bracket contains a time information according to the international standard notation for time and date. This subset can be represented as ±YYYY-MM-DDThh:mm:ss.fZ, see element created for details about the meaning of the glyphs. The value should go down at least to seconds to ensure a unique identifier and to reduce the probability of random collisions.

The third bracket contains a random string as another characteristics to ensure a unique identifier. This avoids collisions with identifiers done by the same institution at the same time.
The bracket has two entries.
Those are separated from each other with a '|'.
The first entry is the number of characters noted in the second entry. If the first entry is empty, the value is implicated from the second. The main purpose is some control and to simplify reading of the second value.
The second entry is the random string.
The characters come from the range [A-Z,a-z,0-9], letters and digits. Additionally for grouping the '-' can be used as well, but not two of them next to each other. The '-' count for the value of the first entry as well.

Example: [Dr. Olaf Hoffmann|LML 2.0|1] [2015-05-18T21:12:37.003Z] [20|Ij8-q61-3PO-mio-8714]

Relations

impressum

Description

Type: Meta (block)

Provides contact information to the person responsible for the document or fragment. This is typically legal information to identify the author or the person responsible for the document or a complete project, the imprint. It can be expected, that such an information is available for any document of a project capable to contain such information and relevant information at all. In a larger project these documents may point only to a document with this information.

In some countries such information is required by laws for publications and specific data have to be provided. This element facilitates to find such information automatically.

Relations

index

Description

Type: Meta (block)

index contains typically an index or table of contents of the document or complete project maybe including references or hyperlinks to the related fragments of the document or project.

A complete project consisting of several files can be provided as a so called widget, gadget or applet too. These are basically new words for an archive, concerning LML, and have no other meaning than an archive. To create an archive with related LML documents, one can simply choose a common and free archive format like tar or zip.

Approach according to LML 1.0:
The initial file containing the index providing access to all chapters, sections, parts of a complete project should be named index.xml (respectively as soon as LML is a well known format: index.lml; authors should use only one of them, if both are provided in doubt for an automatic display of the first archive document index.xml takes precedence).
Additionally the (tar-) archive can be compressed, for example using 'gzip' or 'bzip2'. Typically for web applications there is no need to create an archive, but this can be pretty useful, if complete books or larger works of art or literature are provided for download and are mainly intended for offline reception.

Alternative approach according to LML 2.0:
This variant provides in the archive module for this purpose. It is possible with this module to markup the semantic structure of the archive content and to provide a navigation as normal content.

cu

Description

Type: Attribute

A specific attribute for index and menu cares about a typical problem with reused content (for example with a server script language). The link to the current document is still in the reused index. This superfluous link may confuse users, especially for screen-readers, therefore the link functionality needs to be removed or hidden or the complete link needs to be removed.
The attribute cu (short for: current unified resource identifier) indicates, what the user agent has to do with a link to the current document within the current document (not applicable, if an (additional) fragment identifier is provided).

cu has the possible values:
" _show | _hide | _unlink | * " with * as the name of a replacement (inline) element. If a replacement element is indicated, the related link is presented like the given element without link functionality. For "_show" the link is still shown, for "_hide" the complete link is hidden, for "_unlink" only the link functionality and indication is disabled and only the content is provided. The default is "_unlink".

Relations

interpretation (v2)

Description

Type: Meta (block)

(Subjective) interpretation about the content, the meta information is about.

Relations

keywords

Description

Type: Meta (block)

A container for keywords describing the content of a of the document or document fragment, separated by comma (and additional optional whitespace).

Relations

license

Description

Type: Meta (block)

A container for licence or copyright conditions on the usage of the document or document fragment. This may contain too a so called disclaimer, if required.
Note, that the document is already present for the user, if the license conditions are readable, this cannot be restricted within the same document already for logical reasons. If this is required, other methods have to be used. Note too, that it is pretty useless or even contra-productive to disclaim from consequences due to illegal activities.

Relations

ll

Description

Type: Meta (block)

A container inside the meta element for (a list of) link elements. The links point to the elements the meta information is intended for, if the intended element is not the direct parent of the meta element. This is a list, because the meta information can be related to more than one element, if applicable.

lm

Description

Type: Meta (block)

A container inside the meta element for (a list of) link elements. The links point to (other) meta elements related to the element, the meta information is intended for. This is only necessary, if those meta elements are not direct children of the meta element target, to identify the relation unambiguously. This is a list, because the meta information can be related to more than one element, if applicable.

Description

Type: Meta (block)

A help to navigate within a project or document, contains hyperlinks to other documents of the same project or to fragment identifiers within the same document. cu is a specific attribute for this element.

If menu appears inside meta element, there may be elements rel and rev inside, followed by menu elements or link elements. This means, that the content of the rel or rev indicates a relation between the resources referenced in the following link elements and the meta element target. The relation is applicable for all following siblings until there is another rel or rev indicating another relation.

If menu appears outside a meta element it will typically contain one or more list elements.

Relations

no

Description

Type: Meta (not directly presented)

A container for not directly presented content. Sometimes it might be required to have a container for specific content, intended more for the user-agent than for the user, or such a container may contain otherwise referenced content as the element defs from SVG. SMIL timesheets may require too a container for some additional information about the timesheet.
XHTML has similar elements script and style for other content, not intended for direct presentation, however these elements have a more specific meaning than no.
With styling it can be possible anyway to present the content somehow, but this is not the recommended use of this element. But it is possible to put this element around other content to remove it from presentation for some testing.

Relations

note

Description

Type: Meta (block)

A side note, annotation, gloss, marginal note, incidental remark related to some content, either of the parent element or the relation is specified with a pointer unambiguously from the note to the content and vice versa.

Relations

pid

Description

Type: Meta (inline)

A project fragment identifier. The content is a CURIE typically within the project (sub)domain. Often a larger project is divided in several documents, but each of these documents have some fragments identical within the project. If an author indicates all these identical fragments with the same pid, programs with a none visual presentation may identify this and may provide a mechanism to skip such content if already known to save some time or to show it, if required. This user-agent behaviour is typically not necessary for a visual presentation, because for such a presentation it is typically simple for the user to skip such content without further help. Typical areas for such a help is for example a menu or index area, a header or footer, a logo.

phon

Description

Type: Meta (block)

Indicates the phonetics or pronunciation especially intended for specific words or phrases, problematic neologisms. The element will typically contain phonetic unicode characters or the phrase written with the international phonetic alphabet. Which type of notation is used can be specified with the attribute datatype or typeof. The element may contain a link to an audio representation too, or a switch between several variants or formats.

published

Description

Type: Meta (inline)

The date of publication of the current version of the related document or document fragment. The value is as described for created. However it is published only on one date, a version history can maybe included into release or in desc.

Relations

publishedh (v2)

Description

Type: Meta (block)

This corresponds to the element published, but only for such dates not describable as UTC or TAI. The reason can be, that the UTC is not known or especially for historical reasons not applicable. This is important, because UTC or TAI is pretty meaningless for older documents and not known or known dates are not transformable to UTC or after a transformation these dates are not meaningful for historians anymore. The attributes typeof or datatype should be noted to indicate the used calendar system.

publisher

Description

Type: Meta (inline)

The names of the persons, responsible for the current publication of the related document or document fragment. If there is more than one publisher, this element may contain a grouped list of names using lg or list. The order of publishers is expected to be in such a way, that the main publisher is the first name in the list. The list type may indicate the order of publisher names, if required.
Especially this may appear together or within the element impressum to indicate unambiguously how to contact the responsible publisher. If only one of creator and publisher is available, typically the missing information cannot be directly derived from the available element, however the contact in the impressum should know this information in doubt.

Relations

The following two elements rel and rev (and the related attributes with the same names) indicate relations between documents or document fragments. Such a relation information will typically only indicate the point of view of the current document (fragment) author or editor. Therefore the information might be questionable from another point of view, especially this of the referenced document (fragment) author or editor. To get some reasonable information, in some cases, depending on the claimed relation, one has to explore, if both points of view result in the same conclusion. This is for example critical, if a document claims, that another document is outdated or replaced by the current document. In such a case it should be checked, that the referenced document has a related relation to the current document with a corresponding information. If this is not available, the relation information remains questionable, if there is no other information available about the relation. However, most relations are not really questionable or critical for the referenced document and will not change the meaning or intention of the referenced document from any point of view.

rel

Description

Type: Meta (block)

rel indicates a relation. It appears inside a menu element which appears inside a meta element. menu or link elements are expected to follow the rel element.

The content of the rel indicates a relation between the resources referenced in the following link elements and the meta element target. If more than one relation applies, the relations have to be separated with whitespace.

The content of the rel indicates the purpose or meaning of the referenced resource. For example if this is meta data applicable for a book and rel indicates 'chapter', this means, that the referenced resources are chapters of the book. If there are links to the sections of the chapter too, there may be other menu elements as siblings, then the link to the chapter resource is inside the menu followed by a rel indicating 'section' for the following links to the sections of this chapter of the book.

Or if the relation indicates 'help', then the referenced resources are helps for the meta element target.

Predefined items for rel (and rev) are all LML element names (in general only a subset will be meaningful, but the responsibility for the proper choice is a task for the author or editor). Additionally the following items are predefined:

alternate
Indicates an alternative, typically this is combined with another relation to indicate the type of alternative, if for example used together with translation, this indicates an alternative version in another language.
bookmark
a suggestion for an URI to be used as a bookmark.
dependent
Indicates a dependence between the meta element target and the referenced resource. For the rel it indicates, that the referenced resource depends on the target. The rev indicates, that the target depends on the referenced resource. Such a relation appears for example for translations or a schoolbook or textbook and a collection of exercises or solutions of tasks directly related to the book respectively the exercises.
To indicate such relations can be important to respect author's rights together with other considerations.
profile
Indicates a profile recommendation for extensions. The recommendation has to define, how the extension is applied.
replacement
for a rel the referenced resource replaces the target (and therefore outdated) fragment, for a rev the target replaces the referenced (and therefore outdated) resource.
source
indicates a relation between a copy and the original; rel indicates that the referenced resource is the original and the target a copy, rev the other way around.
translation
Indicates a relation to a translation of the document into another language. The rel indicates, that the target is the original document and the referenced resource a dependent translation, the rev indicates the other direction.
transcription
Indicates a relation to a document containing the same information, but within another format, for example XHTML or SVG instead of LML. The rel indicates, that the target is the original document and the referenced resource a dependent transcription, the rev indicates the other direction.
first
first resource of a collection
last
last resource of a collection
next
next resource of a collection
prev
previous resource of a collection
up
If for example in a book environment there is a systematic global structure of a collection, this refers to the next higher level, for example from a section to the begin of the related chapter, from a chapter to the beginning of a book etc

Because this list is not exhaustive, it may be extended in the future. If an author wants to extend it with a currently not existing relation, the value has to be a safe CURIE: '[' CURIE ']' pointing to a definition of the relation.

Relations

rev

Description

Type: Meta (block)

rev indicates a reverse relation. It appears inside a menu element which appears inside a meta element. menu or link elements are expected to follow the rev element.

The content of the rev indicates a reverse relation between the resources referenced in the following link elements and the meta element target. If more than one relation applies, the relations have to be separated with whitespace.

The content of the rev indicates the purpose or meaning of the meta element target for the referenced resource. For example if this is meta data applicable for a section and rev indicates 'chapter', this means, that the referenced resource is the chapter the section belongs to.

Or if the relation indicates 'help', then the meta element target is a help for the referenced resource.

For more details and predefined items for rev see the element rel.

Relations

Description

Type: Meta (block)

This is a container to refer to related works. It contains typically a list of works somehow related to the current work.

relown (v2)

Description

Type: Meta (block)

This is a container to refer to works from the same authors, not necessarily related to the current work. It contains typically a list of other works from the same authors.

release

Description

Type: Meta (block)

Release or publication data about a document or document fragment. This may contain information like published and publisher too as well as some version history or indication.

Relations

rhyme (v2)

Description

Type: Meta (block)

Specifies the rhyme scheme of poetry content, applicable to a strophe or stanza st or similar structural low level container for poetry content.

The content of the element is an abbreviation for the scheme, typically consisting of single characters [a-z], one for each rhyme, separation with whitespace and comma is allowed. caesura can be indicated with parenthesis for a line and a '!' for the caesura. An enjambement at the end of a line can be indicated by '?'.
Often only small characters [a-z] are sufficient, starting with 'a'. But if this is not sufficient, it is suggested to continue after 'z' with [a-z] directly followed by a positive number, starting with '1'. With this it is possible to provide the rhyme scheme for a text of arbitrary length and complexity, if desired. However, typically one may provide this information for each low level container for poetry content separately to keep it simple, not for a complete poem or drama in one meta information.
Obviously often such additional information about what is already available as content of a poem anyway can be seen as redundant, but if a detailed analysis is intended, this might help to provide it.

Relations

metric (v2)

Description

Type: Meta (block)

This indicates the metrical structure of poetry content, applicable to a strophe line sl (or maybe a strophe st) or similar structural low level container for poetry content.

The content of the element is an abbreviation for the metrical structure of the element. Typically the following syntax can be used, but there might be a need for more symbols for more complex situations: '-' denoting a metrically unstressed syllable (short), '+' a metrically stressed one (long), each '|' a foot boundary, and the '/' a line-end, caesura can be indicated with a '!'. An enjambement at the end of a line can be indicated by '?'.

Relations

role

Description

Type: Meta (no display)

Indicates the role of the meta element target in another host language. This is only meaningful, if LML appears only as indicator for a semantic meaning of elements in other languages, which do not have a role attribute themselves and where it is undesired to use role with a prefix indicating a foreign namespace. For this situation however, the host language must at least have a container for meta information from other namespaces such as the element metadata in SVG. If the role appears outside a meta, but inside of such a foreign meta construction, the related foreign construction defines, to which element the role applies, for SVG metadata as direct parent this is the direct parent of the metadata. Using RDF syntax, the target is indicated with the attribute about.

The role element contains either an LML element name or a safe CURIE to indicate the role.

Note, that the format XHTML+RDFa contains already several attributes to provide a closely related functionality. Especially to indicate the semantic meaning of an element, the attribute property can be used in a similar way to a role concerning literature and LML. Therefore if (X)HTML has to be used, this should be the preferred variant to provide some semantic meaning.

Relations

roles

Description

Type: Meta (no display)

Indicates an attribute representing a role in another host language. This is only meaningful, if LML appears only as indicator for a semantic meaning of elements in other languages, which do not have a role attribute themselves. With this element it is possible to indicate, which attribute takes the role of a role in the current document. This has to have a sufficient syntax for this application.

In (X)HTML and SVG this is the attribute class. Therefore it can be noted formally for example in SVG within the LML namespace: <roles>class</roles>. class consists of a whitespace separated list of class names. After this notation this is restricted to class names with the same names as LML elements or attributes have. The interpretation is, that the elements containing this attribute have the related semantic meaning as it would have with the role attribute in use not available in the currently used language. Other class names not related to LML have to start with 'c_' to indicate them as class names and not roles. For example class="literature c_something" means for this notation type, that the role of the element is that of a literature element and it belongs additionally to the class 'c_something'.

Because the chosen attribute may have other purposes, alternatively another approach can be used too. For this an additional indicator can be added after the attribute name and a whitespace separator: <roles>class l_</roles>. This means, that all names related to LML have a prefix 'l_' before the element or attribute name. For example class="l_literature something" means, that the role of the element is that of a literature element and it belongs additionally to the class 'something'.
Of course one can choose another prefix, for example 'lml_': <roles>class lml_</roles>.

Up to here this does not solve the problem, that often the element roles cannot be used in another language or the language has no method to define a namespace as HTML. For (X)HTML an author should currently consider to use the variant XHTML+RDFa. The new RDFa attributes should be typically sufficient to provide enough semantic meaning for literature combined with CURIEs from LML.
However, for the older (X)HTML variants one can specify one of the methods above using the attribute profile or a link with a profile relation and the element meta in the following way:

  1. Note as profile resource alternatively (or both the first and the second together)
    • in the start tag of the head element:
      profile="http://purl.oclc.org/net/hoffmann/lml/#"
    • in a link element in the head:
      <link rel="profile" href="http://purl.oclc.org/net/hoffmann/lml/#" title="LML" /> (no '/' in HTML)
    • Alternatively use the Dublin Core approach with both:
      In the start tag of the head element:
      profile="http://dublincore.org/documents/2008/08/04/dc-html/"
      In the link element in the head:
      <link rel="schema.lml" href="http://purl.oclc.org/net/hoffmann/lml/#" title="LML" /> (no '/' in HTML)
  2. Note one of the following alternatives:
    • <meta name="roles" content="class" /> (For the Dublin Core approach: <meta name="lml.roles" content="class" />)
    • <meta name="roles" content="class l_" /> (For the Dublin Core approach: <meta name="lml.roles" content="class l_" />)
    • <meta name="roles" content="class lml_" /> (For the Dublin Core approach: <meta name="lml.roles" content="class l_" />)
    • respectively a variant with the preferred prefix not mentioned explicitly here.
    Obviously this applies for XHTML, for HTML remove the '/' specific for XML.
  3. It is possible, that an author wants to use different profiles for different purposes. For this the Dublin Core approach is pretty useful, because it provides a possibility of different schemes with something like prefixes within the names. Otherwise without a schema definition (not recommended) the related meta element(s) must directly follow the link element indicated the profile, the meta belongs to. A later link with rel="profile" indicates, that this profile is applicable for the following meta element(s) and not the previous.
  4. Indicate the roles within the class attribute following the defined syntax and prefix notation.

If for example in SVG it is not intended to use elements from other namespaces within the element metadata, because validation only within the SVG namespace is required for the complete document, another method is defined here, having at least the three above predefined methods available. For this one uses simply the attribute xmlns of the root svg element with one of the following methods:

This namespace is never really used within the document, it is only an indicator for the used method to provide roles within the element class using the indicated method. Unfortunately SVG tiny 1.1 has not class, therefore there is no other way than to use the metadata element for any element, a role has to be provided. In this case and similar other languages, one has to use the element role within the metadata element in any element, a role is required, respectively LML can be used directly in the desc elements to provide structured descriptions (this is a correct use as already mentioned, but typically only validators do not manage to validate such compound documents).

In case, that the profile remains removed from head in 'HTML5' and no role is defined, this causes a new problem in this language to provide semantic information. Note, that the link approach is still ok, even if the relation 'profile' is not predefined in 'HTML5'.
However it is noted, that one can for example place elements from RDF as any metadata directly into the head, this looks like this:


 
       class
 
]]>

respectively the other variants indicating a prefix.

This corresponds to the SVG approach of RDF within metadata (typically that of the root svg).
For 'HTML5' this approach only applies, if sent as application/xhtml+xml. For the text/html variant there is currently no solution in the 'HTML5' draft. If this is not changed, authors may take this as an indication for bad design of 'HTML5' and may not use the text/html variant for semantically relevant content, because it can be considered to be less advanced than the previous HTML4.

Relations

source (v2)

Description

Type: Meta (block)

If the work is derived from other works, it is expected, that this elements contains information about the sources of the work. This can be different types of identifiers or bibcites of other works and references of them, if the information about one resource consists of more than one element, it is expected to be grouped together with g.

Relations

split (v2)

Description

Type: Meta (block)

split is an indicator for content, that is split into parts in different elements. The reason can be for example, that some structure is spread over different lines of a stanza or consists only of parts of these different lines. XML excludes to markup such overlapping structures directly, because always proper nesting of elements has to be ensured. The approach here it to markup each fragment for example with an anchor element a or another element with a fragment identifier. Within the element meta, belonging to a parent of all fragments belonging to one structure, the element split collects all fragment identifiers.
The content of the split starts with one of the following structures:

After this the list of fragment identifiers is noted, each starting with an '#', items separated with whitespace. The order of fragment identifiers indicates the order, the provided meaning applies to.

Reconstruction of the structure: If the referenced fragments are joined together, separated with whitespace, the result represents the complete structure. User agents may provide such functionality on demand.

tip

Description

Type: Meta (block)

A container inside the meta element to provide the tool tip related to the target element. In an advanced viewer for an interactive graphical representation a tool tip becomes often visible as an independent viewport, while the pointing device is over the element. A tool tip is no replacement or alternative for the element, it is only an additional hint or help about some functionality of the element. Therefore for any kind of presentation some minimal interactive demand from the user can be expected to make this hint or help accessible. On the other hand the user-agent may have an indication for elements having tool tips.

Relations

tune

Description

Type: Meta (inline)

A container inside the meta element to indicate the tune, mood, temper, atmosphere or spirit of the target element. If more than one tune applies, the items are separated with whitespace. This might be useful, if the author wants to be sure, that the complete audience is able to understand the intended tune of the text.
Tunes can be grouped together.
A group is indicated with parenthesis, '{' at the beginning, '}' at the end.
A group can contain other groups. An '!' before a group indicates a negation. With a negation it is possible to indicate not intended tune areas to avoid plurivalences.

A list of predefined tune items:

Because this list is not exhaustive, it may be extended in the future. If an author wants to extend it with a currently not existing tune, the value has to be a safe CURIE: '[' CURIE ']' pointing to a definition of the tune.

The predefined items can be translated for display, the expected presentation is the untranslated item first followed by the translation in parenthesis.

version

Description

Type: Meta (inline)

The version of the current fragment. There may be different versions of a document, which can be indicated with this element. The element itself provides no more information about the type of version numbering. To indicate this, additional attributes like typeof or property can be quite useful, if required.

Relations

The elements of this group are intended for text fragments, which are known to be problematic or dubious. They can be corrected or it might be not obvious, how to fix the problem. This might especially occur in texts from old books, if something in a scan or other digitalisation is not readable anymore. Or it turns out, that something was obviously wrong noted in the original work. Another problem may occur for old words, not understandable anymore for current readers.

bug (v2)

Description

Type: Meta (inline)

Indicates a bug or something that need a correction or at least some discussion or comment. The element itself contains the suggested correction, a discussion or a comment about the observed problem. Typically this will be used before publication within proofreading. However, sometimes it might be necessary to keep the original version even for publication, but some indication of a bug is helpful for the audience.

corr (v2)

Description

Type: Meta (inline)

Indicates, that the content is corrected. The element itself contains the original phrase, that was corrected.

Relations

  • TEI: corr

gap (v2)

Description

Type: Meta (inline)

Indicates an missing fragment. It is known, that parts of the original works are missing or lost and therefore within the text there is a gap indicated. The element itself may contain images or scan fragment of the questionable fragment or a link to the scan or bibliographic information about the original work.

Relations

  • TEI: gap

obliterate (v2)

Description

Type: Meta (inline)

Indicates an obliterate, illegible or unreadable fragment. The element itself may contain images or scan fragment of the questionable fragment or a link to the scan or bibliographic information about the original work.

Relations

  • TEI: unclear

orig (v2)

Description

Type: Meta (inline)

Indicates a normalised of modernised phrase. The element itself contains the original notation.

Relations

  • TEI: orig

reg (v2)

Description

Type: Meta (inline)

Indicates a regulated phrase. This change may result due to specific rules. The element itself contains the original notation, typically together with some indication of the regulation rule or a reference to it.

Relations

  • TEI: reg

sic (v2)

Description

Type: Meta (inline)

Indicates an obviously wrong phrase, that is not corrected. The element itself can be empty or can contain a comment or some guess about what went wrong or what might be a correct replacement.

Relations

  • TEI: sic