Ubuntu Manpage: TM::Tau - Topic Maps, Tau Expressions

NAME

       TM::Tau - Topic Maps, Tau Expressions

SYNOPSIS

         use TM::Tau;
         # read a map from an XTM file
         $tm = new TM::Tau ('test.xtm');        # or
         $tm = new TM::Tau ('file:test.xtm');   # or
         $tm = new TM::Tau ('file:test.xtm >'); # or
         $tm = new TM::Tau ('file:test.xtm > null:');

         # read it now and write it back to the file when object goes out of scope
         $tm = new TM::Tau ('test.xtm > test.xtm');

         # create empty map at start and then let it automatically flush onto file
         $tm = new TM::Tau ('null: > test.xtm'); # or
         $tm = new TM::Tau ('> test.xtm');

         # read-in at the start (i.e. constructor time) and then flush it back
         $tm = new TM::Tau ('> test.xtm >');

         # load and merge maps at constructor time
         $tm = new TM::Tau ('file:test.xtm + http://..../test.atm');

         # load map and filter it with a constraint at constructor time
         $tm = new TM::Tau ('mymap.atm * myontology.ont');

         # convert between different formats
         $tm = new TM::Tau ('test.xtm > test.atm');

DESCRIPTION

When you need to make maps persistent, then you can resort to either using the
prefabricated packages TM::Materialized::*, or you can build your own persistent forms
using any of the available synchronizable traits. In either case your application will
have to invoke methods like "sync_in" and "sync_out" to copy content from the resource
into memory and back.

While this gives you great flexibility, in some cases your needs may be much simpler:

consumer model:
A map should be sourced into memory when the map object is created.

A typical use case is a web server application which accesses the map on disk with
every request and which returns parts of the map to an HTTP client.

producer model:
A map is created first in memory and is flushed onto disk at destruction time.

One example here is a script which extracts content from a relational database, puts
it into a map in memory. At the end all map content is copied onto disk.

maintainer model:
A map is sourced from the disk at map object creation time, you update it and it will
be flushed back to the same disk location at object destruction.

Your application may be started with with new content to be put into an existing map.
So first the map will be loaded, the new content added, and after that the map will be
written back from where it came.

translator model:
A map is sourced from the disk, is translated into some other representation and is
written back to disk to another location or format.

As an example, you might want to convert between XTM and CTM format.

filter model:
A map is sourced from some backend, is transformed and/or filtered before being used.

Your application could be one which only needs a particular portion of the map. So
before processing the map is filtered down to the necessary parts.

integration model:
One or more maps are sourced from backends and are merged before processing.

If you want to provide a consolidated view over several different data resources, you
could first bring them all into topic map form, and then merge them before handing it
to the application.

What is common to all these cases is that there is a breath-in phase when the map object
is constructed, and a breath-out phase when it is destroyed. In between theses phases the
map object is just a normal instance of TM.

TAU EXPRESSIONS

   Overview
       To control what happens in these two phases, this package provides a simple expression
       language, call Tau. With it you can control

       •   where maps are supposed to come from, or go to,

           Here the language provides a URI mechanism for addressing, such as

              file:tm.atm

           or

              http://topicmaps/some/map.xtm

       •   when (or how) they should be merged,

           To merge two (manifested or virtual) topic maps together the "+" operator can be used

              file:tm.atm + http://topicmaps/some/map.xtm

       •   when (or how) they should be transformed,

           To transform product data to only something a customer is supposed to see, the "*" can
           be used:

              product_data.atm * file:customer_view.tmql

       •   when (or whether at all) they should be loaded oder saved

       NOTE: Later versions of this package will heavily overload the operators to also operate
       on other objects.

   Syntax
       The Tau expression language supports two binary operators, "+" and "*". The "+" operator
       intuitively puts things together, the "*" applies the right-hand operand to the left-hand
       operand and behaves as a transformer or a filter. The exact semantics depends on the
       operands. In any case, the "*" binds stronger than the "+", and that precedence order can
       be overridden with parentheses.

       The parser understands the following syntax for Tau expression:

          tau_expr    -> mul_expr

          mul_expr    -> source { ('>' | '*') filter }

          source      -> '(' add_expr ')' | primitive

          add_expr    -> mul_expr { '+' mul_expr }

          filter      -> '(' filter ')' | primitive

          primitive   -> uri [ module_spec ]

          module_spec -> '{' name '}'

       Terms in quotes are terminals, terms inside {} can appear any number of times (also zero),
       terms inside [] are optional. All other terms are non-terminals.

       NOTE: Filters are planned to be composite, hence the optional bracketing in the grammar.

       The (pre)parser supports the following shortcuts (I hate unnecessary typing):

       •   "whatever" is interpreted as "(whatever) > -"

       •   "whatever >" is interpreted as "(whatever) > -"

       •   "> whatever" is interpreted as  "- > (whatever)"

       •   "< whatever >" is interpreted as "whatever > whatever", sync_in => 0

       •   "> whatever <" is interpreted as "whatever > whatever", sync_out => 0

       •   "> whatever >" is interpreted as "whatever > whatever"

       •   "< whatever <" is interpreted as "whatever > whatever", sync_in => 0, sync_out => 0

       •   The URI "-" as source is interpreted as STDIN (via the TM::Serializable::AsTMa trait).
           Unless you override that.

       •   The URI "-" as filter is interpreted as STDOUT (via the TM::Serializable::Dumper
           trait).  Unless you override that.

   Examples
         # memory-only map
         null: > null:

         # read at startup, sync out when map goes out of scope
         file:test.atm > file:test.atm

         # copy AsTMa= to XTM
         file:test.atm > file:test.xtm

         # using a dedicated driver to load a map, store it onto a file
         dns:my.dns.server { My::DNS::Driver } > file:dns_snapshot.atm
         # this will only work if the My::DNS::Driver supports to materialize
         # the whole map

         # read a map and compute the statistics
         file:test.atm * http://psi.tm.bond.edu.au/queries/1.0/statistics

   Map Source URLs
       URIs are used to address maps. An XTM map, for example, stored in the file system might be
       addressed as

         file:mydir/somemap.xtm

       for a relative URL (relative to an application's current working directory), or via an
       absolute URI such as

         http://myserver/somemap.atm

       The package supports all those access methods (file:, http:, ...) which LWP supports.

   Drivers
       Obviously a different deserializer package has to be used for an XTM file than for an
       AsTMa or LTM file. Some topic map content may be in a TM backend database, some content
       may only exist virtually, being emulated by a dedicated package.  While you may be mostly
       fine with system defaults, in some cases you may want to have precise control on how files
       and other external sources are to be interpreted. By their nature, drivers for sources
       must be subclasses of TM.

       A similar consideration applies to filters. Also here the specified URI determines which
       filter actually has to be applied. It also can define where the content eventually is
       stored to. Drivers for filters must be either subclasses of TM::Tau::Filter, or
       alternatively must be a trait providing a method "sync_out".

   Binding by Schemes (implicit)
       When a Tau expression is parsed, the parser tries to identify which driver to use for
       which part of that composite map denoted by the expression. For this purpose a pattern
       matching approach is used to map regular expression patterns to driver package names. If
       you would like to learn about the current state of affairs do a

          use Data::Dumper;
          print Dumper \%TM::Tau::sources;
          print Dumper \%TM::Tau::filters;

       Obviously, there is a distinction made between the namespace of resources (residing data)
       and filters (and transformers).

       Each entry in any of the hashes contains as key a regular expression and as value the name
       of the driver to be used. That key is matched against the parsed URI and the first match
       wins. Since the keys in a hash are not naturally ordered, that is undefined.

       At any time you can override values there:

          $TM::Tau::sources{'null:'}          = 'TM';
          $TM::Tau::sources{'tm:server\.com'} = 'My::Private::TopicMap::Driver';

       or delete existing ones. The only constraint is that the driver package must already be
       "require"d into your Perl program.

       During parsing of a Tau expression, two cases are distinguished:

       •   If the URI specifies a source, then this URI will be matched against the regexps in
           the "TM::Tau::sources" hash. The value of that entry will be used as class name to
           instantiate an object whereby one component ("uri") will be passed as parameter like
           this:

           $this_class_name->new (uri => $this_uri, baseuri => $this_uri)

           This class should be a subclass of TM.

       •   If the URI specifies a filter, then you have two options: Either you use as entry the
           name of a subclass of TM::Tau::Filter. Then an object is created like above.
           Alternatively, the entry is a list reference containing names of traits. Then a
           generic TM::Tau::Filter node is generated first and each of the traits are applied
           like this:

           Class::Trait->apply ( $node => $trait => {
                                          exclude => [ 'mtime',
                                                       'sync_out',
                                                       'source_in' ]
                                          } );

       If there is no match, this results in an exception.

   Binding by Package Pragmas (Explicit)
       Another way to define which package should be used for a particular map is to specify this
       directly in the tau expression:

          http://.../map.xtm { My::BrokenXTM }

       In this case the resource is loaded and is processed using "My::BrokenXTM" as package to
       parse it (see TM::Materialized::Stream on how to write such a driver).

INTERFACE

   Constructor
       The constructor accepts a string following the Tau expression "Syntax".  If that string is
       missing, "null:" will be assumed. An appropriate exception will be raised if the syntax is
       violated or one of the mentioned drivers is not preloaded.

       Examples:

          # map only existing in memory
          my $map = new TM::Tau;

          # map will be loaded as result of this tau expression
          my $map = new TM::Tau ('file:music.atm * file:beatles.tmql');

       Apart from the Tau expression the constructor optionally interprets a hash with the
       following keys:

       "sync_in" (default: 1)
           If non-zero, in-synchronisation at constructor time will happen, otherwise it is
           suppressed. In that case you can trigger in-synchronisation explicitly with the method
           "sync_in".

       "sync_out" (default: 1)
           If non-zero, out-synchronisation at destruction time will happen, otherwise it is
           suppressed.

       Example:

          my $map = new TM::Tau ('test.xtm',
                                 sync_in => 0); # dont want to let it happen now
          ....                                  # time passes
          $map->sync_in;                        # but now is a good time

AUTHOR