Topic maps, tau expressions
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');
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 \*(C`sync_in\*(C' and \*(C`sync_out\*(C' 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:
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 \s-1HTTP\s0 client.
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.
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.
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 \s-1XTM\s0 and \s-1CTM\s0 format.
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.
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 \s-1TM\s0.
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 \s-1URI\s0 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 \*(C`+\*(C' 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 \*(C`*\*(C' can be used: product_data.atm * file:customer_view.tmql
when (or whether at all) they should be loaded oder saved
\s-1NOTE\s0: Later versions of this package will heavily overload the operators to also operate on other objects.
The Tau expression language supports two binary operators, \*(C`+\*(C' and \*(C`*\*(C'. The \*(C`+\*(C' operator intuitively puts things together, the \*(C`*\*(C' 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 \*(C`*\*(C' binds stronger than the \*(C`+\*(C', 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.
\s-1NOTE\s0: Filters are planned to be composite, hence the optional bracketing in the grammar.
The (pre)parser supports the following shortcuts (I hate unnecessary typing):
\*(L"whatever\*(R" is interpreted as \*(L"(whatever) > -\*(R"
\*(L"whatever >\*(R" is interpreted as \*(L"(whatever) > -\*(R"
\*(L"> whatever\*(R" is interpreted as \*(L"- > (whatever)\*(R"
\*(L"< whatever >\*(R" is interpreted as \*(L"whatever > whatever\*(R", sync_in => 0
\*(L"> whatever <\*(R" is interpreted as \*(L"whatever > whatever\*(R", sync_out => 0
\*(L"> whatever >\*(R" is interpreted as \*(L"whatever > whatever\*(R"
\*(L"< whatever <\*(R" is interpreted as \*(L"whatever > whatever\*(R", sync_in => 0, sync_out => 0
The \s-1URI\s0 \*(C`-\*(C' as source is interpreted as \s-1STDIN\s0 (via the TM::Serializable::AsTMa trait). Unless you override that.
The \s-1URI\s0 \*(C`-\*(C' as filter is interpreted as \s-1STDOUT\s0 (via the TM::Serializable::Dumper trait). Unless you override that.
# 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
URIs are used to address maps. An \s-1XTM\s0 map, for example, stored in the file system might be addressed as
file:mydir/somemap.xtm
for a relative \s-1URL\s0 (relative to an application's current working directory), or via an absolute \s-1URI\s0 such as
http://myserver/somemap.atm
The package supports all those access methods (file:, http:, ...) which \s-1LWP\s0 supports.
Obviously a different deserializer package has to be used for an \s-1XTM\s0 file than for an AsTMa or \s-1LTM\s0 file. Some topic map content may be in a \s-1TM\s0 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 \s-1TM\s0.
A similar consideration applies to filters. Also here the specified \s-1URI\s0 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 \*(C`sync_out\*(C'.
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 \s-1URI\s0 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 \*(C`require\*(C'd into your Perl program.
During parsing of a Tau expression, two cases are distinguished:
If the \s-1URI\s0 specifies a source, then this \s-1URI\s0 will be matched against the regexps in the \*(C`TM::Tau::sources\*(C' hash. The value of that entry will be used as class name to instantiate an object whereby one component (\*(C`uri\*(C') will be passed as parameter like this: $this_class_name->new (uri => $this_uri, baseuri => $this_uri) This class should be a subclass of \s-1TM\s0.
If the \s-1URI\s0 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.
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 \*(C`My::BrokenXTM\*(C' as package to parse it (see TM::Materialized::Stream on how to write such a driver).
The constructor accepts a string following the Tau expression \*(L"Syntax\*(R". If that string is missing, \*(C`null:\*(C' 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: 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 \*(C`sync_in\*(C'. 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
\s-1TM\s0, TM::Tau::Filter
Copyright 200[0-68], Robert Barta <[email protected]>, All rights reserved.
This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself. http://www.perl.com/perl/misc/Artistic.html