[topicmapmail] Draft of LTM 1.2

[Lars Marius Garshol]

Since some of the people on this list have shown interest in LTM
before, I'm posting this here, so that people can comment on it if
they wish. If you don't want to send your comments to the list you can
send them to me privately.

If you have no idea what LTM is, see
  <URL: http://www.ontopia.net/download/ltm.html >


  LTM 1.2
=========

The LTM 1.1 topic map notation has been in use for a while now, and
some of its limitations are beginning to be felt as awkward. The time
has therefore come to extend the notation to avoid the most annoying
of these limitations, which we think can be done at low cost in terms
of implementation effort and language size.

Note that the grammar definitions in this document refer to those in
the LTM 1.1 specification:

  <URL: http://www.ontopia.net/download/ltm.html >

The input of Murray Altheim, who suggested some of the syntax in this
proposal, is gratefully acknowledged.


  REIFICATION OF THE TOPIC MAP
------------------------------

This is something users very often want to do, in order to get the
Omnigator to display a title for the topic map, and also to put
version and description information into the topic map in a convenient
way. There currently exists a hack to do this, but we would like to
discontinue its use.

The solution might be to define an ID for the topic map topic in this
way:

  topicmap-id ::= '#' 'TOPICMAP' WS NAME

This would give the topic map a source locator of the form
base-uri#NAME, and multiple such declarations would be allowed (each
giving a different source locator).

An example of use:

  #TOPICMAP example

  [tm-topic = "An example topic map"
   @"#example"]

The subject indicator of the topic here points to the topic map's
source locator, indicating that the topic reifies the topic map.

ISSUE: What if there is a topic with ID 'example'?

ISSUE: Should we require the topic map and topic IDs to match, and
       instead create a 'random' source locator for the topic map
       under the covers, with a subject indicator reference from the
       topic?


  INCLUSION OF EXTERNAL TOPIC MAPS
----------------------------------

Splitting large topic maps up into separate files can make their
maintenance substantially easier, and at the same time opens for reuse
of individual modules. This is one of the most frequently requested
features of LTM, and will therefore be included in this version.

The best solution may be to have two directives, one for inclusion
into the same ID namespace, and one for import into a different ID
namespace. 

The first may look as follows:

  include ::= '#' 'INCLUDE' WS STRING

where the STRING is a URI reference to the LTM topic map to import.
This inclusion mechanism will cause the external LTM file to be
treated as if its content had been included at the point of reference.
The benefit is that this makes merging much easier to specify for the
authors.

ISSUE: Is this actually quite stupid? It will cause the source
       locators of the included topics to have source locators based
       on the including TM. What to do then about any "#foo" URI
       references in the included topic map?


The second, import into a different ID namespace, may look as follows:

  mergemap ::= '#' 'MERGEMAP' WS STRING (WS syntax)?

  syntax   ::= 'hytm' | 'xtm' | 'ltm' | 'astma'

where the STRING is a URI reference to the external topic map. This
topic map can be in any syntax, and users can specify which syntax is
used. If the syntax is not specified it is assumed to be LTM.

The processing will be described as loading the other topic map, and
then merging by subject indicator and subject address, optionally also
by the topic naming constraint.

ISSUE: Better to require LTM syntax? Or just LTM and XTM?

Examples of use:

  #INCLUDE "geography.ltm"
  #MERGEMAP "country.xtm" xtm


  SETTING BASE URI
------------------

Another feature that has been requested by users is the ability to
specify a base URI for the topic map, against which relative URIs are
to be resolved. This can make editing much easier in cases when most
of the occurrences are are online at the same location, or when most
subject indicators have the same base URI.

This could be specified using the same 'directive' syntax as above:

  baseuri ::= '#' 'BASEURI' STRING

All instances of STRING in the topic map that occur after this
directive will then be resolved relative to this URI, rather than the
document URI. Note that this does *not* apply to intra-document URI
references, that is, URIs beginning with '#', which will still be
resolved relative to the current document URI.

An example of use:

  #BASEURI "http://www.acme.com/topic-site/"

ISSUE: Is this important enough to warrant inclusion?


  SCOPING OCCURRENCES AND ASSOCIATIONS
--------------------------------------

The scoping of occurrences and associations is quite common, but still
not supported by LTM 1.1. This is one of the restrictions that has
been felt the strongest by users in practice, and it is therefore
being lifted in this version.

This is easily done by modifying the 'assoc' and 'occur' productions
in the syntax as follows:

  assoc ::= scope? NAME '(' assoc-role (',' assoc-role)*  ')'

  occur ::= scope? '{' occ-topic ',' occ-type ',' resource '}'

Examples of use:

  / english {xml, specification, "http://www.w3.org/TR/REC-xml"}

  / daniels instance-of(devanagari : instance, abugida : class)
  / bright  instance-of(devanagari : instance, alphasyllabary : class)

ISSUE: This causes LTM 1.2 to be LL(3), which may be a little much.
       Should we put the scope inside the curlies in occurrences? 
       It will look a little funny, perhaps?


  SUMMARY OF GRAMMAR CHANGES
----------------------------

To make these changes, the following grammar symbols must be changed:

  topic-map   ::= encoding? directive* (topic | assoc | occur) +
	      
  assoc       ::= scope? NAME '(' assoc-role (',' assoc-role)*  ')'
	      
  occur       ::= scope? '{' occ-topic ',' occ-type ',' resource '}'


The following symbols must be added:

  directive   ::= baseuri | topicmap-id | include | mergemap

  topicmap-id ::= '#' 'TOPICMAP' WS NAME

  include     ::= '#' 'INCLUDE' WS STRING

  mergemap    ::= '#' 'MERGEMAP' WS STRING (WS syntax)?

  syntax      ::= 'hytm' | 'xtm' | 'ltm' | 'astma'

  baseuri     ::= '#' 'BASEURI' STRING


--Lars M.