This module belongs to the Literature Markup Language Version 2.0
There are many new elements in LML 2.0 indicated in the element index with (v2).
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.
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.
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.
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.
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.
desccontentinfodescriptiondescriptiondescType: 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.
bibliographicCitationType: 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.
citecitecitation and some related elementsbibliographicCitationcitebiblciteType: 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.
conformsToType: 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.
coverageType: 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.
spatialType: 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.
datelinedatedatecreatedmodifiedupdateddate in creationType: 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.
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: 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:
docauthorauthorcreatorauthorauthorauthor, editor etcType: 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: Attribute
type refines the meaning of the element due to the contribution.
See the same attribute for creator: type
collabothercreditcontributorcontributorType: 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.
distributorType: 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.
authorityType: 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.
revisionDescType: 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.
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.
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§'.
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]'
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]
biblioidisbnissnidentifieridid, isbnguididnoType: 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.
addressdocauthorauthor (and children elements)legalnoticeimprintType: 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.
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".
indextableOfContentsitemsindexType: Meta (block)
(Subjective) interpretation about the content, the meta information is about.
interpretationType: Meta (block)
A container for keywords describing the content of a of the document or document fragment, separated by comma (and additional optional whitespace).
keywordsetkeywordkeywordskeywordsType: 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.
copyrighttrademarklicenserightsaccessRightsrightscopyrightdisclaimerlicenseType: 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.
Type: Meta (block)
A container inside the meta element for (a list of)
link elements. The links point to (other) metameta 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.
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.
menunavigationType: 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.
defsType: 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.
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.
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.
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.
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.
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.
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.
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:
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.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.
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.
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.
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.
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.
releaseinfoprinthistoryrevhistorybookinfodocument-info, publish-info, custom-info, version, historyType: 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.
rhyme, obviously other syntax, but same meaningType: 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 '?'.
met and real, obviously other syntax, but same meaningType: 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.
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:
head element:link element in the head:head element:link element in the head: <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_" />) 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.
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: