Provided by: libtm-perl_1.56-8_all bug

NAME

       TM - Topic Maps, Base Class

SYNOPSIS

           my $tm = new TM (baseuri => 'tm://whatever/');   # empty map

           # add a toplet (= minimal topic, only identification, no characteristics)
           # by specifying an internal ID
           $tm->internalize ('aaa');                        # only internal identifier
           $tm->internalize ('bbb' =>   'http://bbb/');     # with a subject address
           $tm->internalize ('ccc' => \ 'http://ccc/');     # with a subject indicator

           # without specifying an internal ID (will be auto-generated)
           $tm->internalize (undef =>   'http://ccc/');     # with a subject address
           $tm->internalize (undef => \ 'http://ccc/');     # with a subject indicator

           # get rid of toplet(s)
           $tm->externalize ('tm://whatever/aaa', ...);

           # find full URI of a toplet
           my $tid  = $tm->tids ('person');                     # returns tm://whatever/person
           my @tids = $tm->tids ('person', ...)                 # for a whole list

           my $tid  = $tm->tids (  'http://bbb/');              # with subject address
           my $tid  = $tm->tids (\ 'http://ccc/');              # with subject indicator

           my @ts   = $tm->toplets;                             # get all toplets
           my @ts   = $tm->toplets (\ '+all -infrastructure');  # only those you added

           my @as   = $tm->asserts (\ '+all -infrastructure');  # only those you added

           my @as   = $tm->retrieve;                            # all assertions
           my $a    = $tm->retrieve ('23ac4637....345');        # returns only that one assertion
           my @as   = $tm->retrieve ('23ac4637....345', '...'); # returns all these assertions

           # create standalone assertion
           my $a = Assertion->new (type    => 'is-subclass-of',
                                   roles   => [ 'subclass', 'superclass' ],
                                   players => [ 'rumsti', 'ramsti' ]);
           $tm->assert ($a);                                    # add that to map

           # create a name
           my $n = Assertion->new (kind    => TM->NAME,
                                   type    => 'name',
                                   scope   => 'us',
                                   roles   => [ 'thing', 'value' ],
                                   players => [ 'rumsti', new TM::Literal ('AAA') ])
           # create an occurrence
           my $o = Assertion->new (kind    => TM->OCC,
                                   type    => 'occurrence',
                                   scope   => 'us',
                                   roles   => [ 'thing', 'value' ],
                                   players => [ 'rumsti', new TM::Literal ('http://whatever/') ])

           $tm->assert ($n, $o);                                # throw them in

           $tm->retract ($a->[TM->LID], ...);                   # get rid of assertion(s)

           my @as = $tm->retrieve ('id..of...assertion');       # extract particular assertions

           # find particular assertions
           # generic search patterns
           my @as = $tm->match_forall (scope   => 'tm://whatever/sss');

           my @bs = $tm->match_forall (type    => 'tm://whatever/ttt',
                                       roles   => [ 'tm://whatever/aaa', 'tm://whatever/bbb' ]);

           # specialized search patterns (see TM::Axes)
           my @cs = $tm->match_forall (type    => 'is-subclass-of',
                                       arole   => 'superclass',
                                       aplayer => 'tm://whatever/rumsti',
                                       brole   => 'subclass');

           my @ds = $tm->match_forall (type    => 'isa',
                                       class   => 'tm://whatever/person');

           # perform merging, cleanup, etc.
           $tm->consolidate;

           # check internal consistency of the data structure
           die "panic" if $tm->insane;

           # taxonomy stuff
           warn "what a subtle joke" if $tm->is_a ($tm->tids ('gw_bush', 'moron'));

           die "what a subtle joke"
               unless $tm->is_subclass ($tm->tids ('politician', 'moron'));

           # returns Mr. Spock if Volcans are subclassing Aliens
           warn "my best friends: ". Dumper [ $tm->instancesT ($tm->tids ('alien')) ];

ABSTRACT

       This class provides read/write access to a data structure according to the Topic Maps
       paradigm. As it stands, this class implements directly so-called materialized maps, i.e.
       those maps which completely reside in memory. Implementations for non-materialized maps
       can be derived from it.

DESCRIPTION

       This class implements directly so-called materialized topic maps, i.e. those maps which
       completely reside in memory. Non-materialized and non-materializable maps can be
       implemented by deriving from this class by overloading one or all of the sub-interfaces.
       If this is done cleverly, then any application, even a TMQL query processor can operate on
       non-materialized (virtual) maps in the same way as on materialized ones.

   Data Structures
       The Topic Maps paradigm knows two abstractions

       TMDM, Topic Maps Data Model
           <http://www.isotopicmaps.org/sam/sam-model/>

       TMRM, Topic Maps Reference Model
           <http://www.isotopicmaps.org/tmrm/>

       For historical reasons, this package adopts an abstraction which is in between these two.
       Accordingly, there are only following types of data structures

       Toplets:
           These are like TMDM topics, but only contain addressing information (subject
           identifiers and subject addresses) along with an internal identifier.

       Assertions:
           These are like TMDM associations, but are generalized to host also occurrences and
           names. Also associations using predefined association types, such as "isa" (instance-
           class) and "iko" (subtype-supertype) are represented as assertions.

       Variants:
           No idea what they are good for. They can be probably safely ignored.

       The data manipulation interface is very low-level and directly exposes internal data
       structures.  As long as you do not mess with the information you get and you follow the
       API rules, this can provide a convenient, fast, albeit not overly comfortable interface.
       If you prefer more a TMDM-like style of accessing a map then have a look at TM::DM.

   Identifiers
       Of course, TM supports the subject locator and the subject indicator mechanism as mandated
       by the Topic Maps standards.

       Additionally, this package also uses internal identifiers to address everything which
       looks and smells like a topic, also associations, names and occurrences. For topics the
       application (or author) of the topic map will most likely provide these internal
       identifiers. For the others the identifiers are generated.

       Since v1.31 this package distinguishes between 3 kinds of internal identifiers:

       canonicalized toplet identifiers
           These identifiers are always interpreted local to a map, in that the "baseuri" of the
           map is used as prefix. So, a local identifier

             chinese-working-conditions

           will become

             tm://nirvana/chinese-working-conditions

           if the base URI of the map were

             tm://nirvana/

           So if you want to use identifiers such as these, then you should either use the
           absolut version (including the base URI) or use the method "tids" to find the absolute
           version.

       sacrosanct toplet identifiers
           All toplets from the infrastructure are declared sacrosanct, i.e. untouchable.
           Examples are "isa", "class" or "us" (universal scope).

           These identifiers are always the same in all maps this package system manages. That
           implies that if you use such an identifier, then you cannot attach a local meaning to
           it. And it implies that at merging time, toplets with these identifiers will merge.
           Even if there were no subject indicators or addresses involved.

           It is probably a good idea to leave such toplets alone as the software is relying on
           the stability of the sacrosanct identifiers.

       assertion identifiers
           Each assertion also has an (internal) identifier. It is a function from the content,
           so it is characteristic for the assertion.

   Consistency
       An application using a map may expect that a map is consolidated, i.e. that the following
       consistency conditions are met:

       A1 (fixed on)
           Every identifier appearing in some assertion as type, scope, role or player is also
           registered as toplet.

       Indicator_based_Merging (default: on)
           Two (or more) toplets sharing the same subject identifier are treated as one toplet.

       Subject_based_Merging (default: on)
           Two (or more) toplets sharing the same subject locator are treated as one toplet.

       TNC_based_Merging (default: off)
           Two (or more) toplet sharing the same name in the same scope are treated as one
           toplet.

       While A1 is related with the internal consistency of the data structure (see "insane"),
       the others are a choice the application can make (see "consistency").

       Consistency is not automatically provided when a map is modified by the application. It is
       the applications responsibility to trigger the process to consolidate the map. As that may
       be potentially expensive, the control remains at the application.

       When an IO driver is consuming a map from a resource, say, loading from an XTM file, then
       that driver will ensure that the map is consolidated according to the current settings
       before it hands it to the application. The application is then in full control of the map
       as it can change, add and delete toplets and assertions. The map can become unconsolidated
       in this process. The method "consolidate" reinstates consistency again.

       You can change these defaults by (a) providing an additional option to the constructor

          new TM (....,
                  consistency => [ TM->Subject_based_Merging,
                                   TM->Indicator_based_Merging ]);

       or (b) by later using the accessor "consistency" (see below).

MAP INTERFACE

   Constructor
       $tm = new TM (...)

       The constructor will create an empty map, or, to be more exact, it will fill the map with
       the taxonomy from TM::PSI which covers basic Topic Maps concepts such as topic or
       associations.

       The constructor understands a number of key/value pair parameters:

       "baseuri" (default: "tm://nirvana/")
           Every toplet in the map has an unique local identifier (e.g. "shoesize"). The
           "baseuri" parameter controls how an absolute URI is built from this identifier.

       "consistency" (default: [ Subject_based_Merging, Indicator_based_Merging ])
           This controls the consistency settings. They can be changed later with the
           "consistency" method.

   Methods
       baseuri
           $bu = $tm->baseuri

           This methods retrieves the base URI component of the map. This is a read-only method.
           The base URI is always defined.

       consistency
           @merging_constraints = $tm->consistency

           $tm->consistency (@list_of_consistency_constants)

           This method provides read/write access to the consistency settings.

           If no parameters are provided, then the current list of consistency settings is
           returned. If parameters are provided, that list must consist of the constants defined
           under "Consistency".

           NOTE: Changing the consistency does NOT automatically trigger "consolidate".

       last_mod
           Returns the Time::HiRes date of last time the map has been modified (content-wise).

       consolidate
           $tm->consolidate

           $tm->consolidate (@list_of_consistency_constants)

           This method consolidates a map by performing the following actions:

           •   perform merging based on subject address (see TMDM section 5.3.2)

           •   perform merging based on subject indicators (see TMDM section 5.3.2)

           •   remove all superfluous toplets (those which do not take part in any assertion)

               NOTE: Not implemented yet!

           This method will normally use the map's consistency settings. These settings can be
           overridden by adding consistency settings as parameters (see "Consistency"). In that
           case the map's settings are not modified, so use this carefully.

           NOTE: In all cases the map will be modified.

           NOTE: After merging some of the lids might not be reliably point to a topic.

       clear
           $tm->clear

           This method removes all toplets and assertions (except the infrastructure). Everything
           else remains.

       add $tm->add ($tm2, ...)

           This method accepts a list of TM objects and adds all content from these maps to the
           current object.

           NOTE: There is NO merging done for user-supplied toplets. Use explicitly method
           "consolidate" for it. Merging is done for all sacrosanct toplets, i.e. those from the
           infrastructure.

           From v1.31 onwards this method tries to favour the internal identifiers (LIDs) of this
           map over LIDs of the added maps. This means, firstly, that internal identifiers of
           this map are not touched (or re-generated) in any way and that any shorthands (without
           a baseuri prefix) will remain valid when using "tids". Secondly, LIDs in the added map
           will be attempted to blend into this map by changing simply their prefix. If that
           newly generated LID is already taken by something in this map, then the original LID
           will be used. That allows many added LIDs be used together with "tids" without (much)
           change in code. Of course, the only reliable way to reach a topic is a subject locator
           or an indicator. This is all about convenience.

           NOTE: This procedure implies that some assertions are recomputed, so that also their
           LID will change!

       diff
           $diff = $new_tm->diff ($old_tm)

           $diff = TM::diff ($new_tm, $old_tm)

           $diff = TM::diff ($new_tm, $old_tm,
                                {consistency => \ @list_of_consistency_consts,
                                 include_changes => 1})

           "diff" compares two topic maps and returns their differences as a hash reference.
           While it works on any two maps, it is most useful after one map (the old map) is
           modified into a new map.

           If "diff" is used in OO-style, the current map is interpreted as the new map and the
           map in the arguments as the old one.

           By default, the toplet and assertion identifiers for any changes are returned; the
           option "include_changes" causes the return of the actual toplets and assertions
           themselves. This option makes "diff"'s output more self-contained: enabled, one can
           fully (re)create the new map from the old one using the diff (or vice versa).

           The "consistency" option uses the same format as the TM constructor (see
           "Constructor") and describes how corresponding toplets in the two maps are to be
           identified.  Toplets with the same internal ids are always considered equal. If
           subject based consistency is active, toplets with the same subject locator are
           considered equal (overriding the topic identities).  If indicator based consistency is
           active, toplets with a matching subject indicator are considered equal (overriding the
           previous identities).

           NOTE: This overriding of previous conditions for identity is necessary to keep the
           equality relationship unique and one-to-one.  As an example, consider the following
           scenario: a toplet a in the old map is split into multiple new toplets a and b in the
           new map. If a had a locator or identifier that is moved to b (and if consistency
           options were active), then the identity detector will consider b to be equal to a, and
           not a in the new map to correspond to a in the old map.  However, this will never lead
           to loss of information: a in the new map is flagged as completely new toplet.

           The differences between old and new map are returned underneath the keys plus, minus,
           identities and modified. If "include_changes" is on, the extra keys plus_midlets,
           minus_midlets and assertions are populated. The values of all these keys are hash
           references themselves.

           plus, minus
               The "plus" and "minus" hashes list new or removed toplets, respectively (with
               their identifiers as keys).  For each toplet, the value of the hash is an array of
               associated assertion ids. The array is empty but defined if there are no
               associated assertions.

               For toplets the attached assertions are the usual ones (names, occurrences) and
               class-instance relationships (attached to the instance toplet).

               For associations, the assertions are attached to the type toplet.

           identities
               This hash consists of the non-trivial toplet identities that were found. If
               neither Subject- nor Indicator-based merging is active and if neither map object
               was created with a TM version before 1.31, then this hash is empty. Otherwise, the
               keys are toplet identifiers in the old map, with the corresponding topic
               identifier in the new map as value. This includes standalone topics as well as
               assertions and associations that were renamed due to changed player or role
               identities.

               For diff operations between maps where one map was created with a TM version
               before 1.31 (which can happen with frozen/thawed or MLDBM-based maps) extra
               identifying steps are performed (because the identifier format for assertions and
               infrastructure toplets and the stored format of toplets have changed). This
               situation is detected automatically, and if so the identities hash will also
               include all map elements that were identical but have different names due to the
               version incompatibility.

           modified
               The modified hash contains the changes for matched toplets. The key is the toplet
               identifier in the old map (which is potentially different from the one in the new
               map; see the note about identities above). The value is a hash with three keys:
               plus, minus and identities.  The value for the "identities" key is defined if and
               only if the toplet associated with this toplet has changed (i.e. Subject Locator
               or Indicators have changed).  The values for the "plus" and "minus" keys are
               arrays with the new or removed assertions that are attached to this toplet. These
               arrays are defined but empty where no applicable information is present.

           plus_midlets, minus_midlets
               These hashes hold the actual new or removed toplets if the option
               "include_changes" is active.  Keys are the toplet ids, values are references to
               the actual toplet data structures.

           assertions
               This hash holds the actual assertions where the maps differ; it exists only if the
               option "include_changes" is active. Keys are the assertion identifiers, values the
               references to the actual assertion data structure. Note that assertion ids
               uniquely identify the assertion contents, therefore this hash can hold assertions
               from both new and old map.

       melt (DEPRECATED)
           $tm->melt ($tm2)

           This - probably more auxiliary - function copies relevant aspect of a second map into
           the object.

       insane
           warn "topic map broken" if $tm->insane

           This method tests invariant conditions inside the TM structure of that map.
           Specifically,

           •   each toplet has a LID which points to a toplet with the same address

           It returns a string with a message or "undef" if everything seems fine.

           TODO: add test whether all variant entries have a proper LID (and toplet)

TOPLET INTERFACE

       Toplets are light-weight versions of TMDM topics. They only carry addressing information
       and are represented by an array (struct) with the following fields:

       "lid" (index: "LID")
           The internal identifier. Mostly it repeats the key in the toplet hash, but also
           aliased identifiers may exist.

       "saddr" (index: "ADDRESS")
           It contains the subject locator (address) URI, if known. Otherwise "undef".

       "sinds" (index: "INDICATORS")
           This is a reference to a list containing subject identifiers (indicators). The list
           can be empty, no duplicate removal is attempted at this stage.

       You can create this structure manually, but mostly you would leave it to "internalize" to
       do the work.

       Example:

          # dogmatic way to produce it
          my $to = Toplet->new (lid   => $baseuri . 'my-lovely-cat',
                                saddr => 'http://subject-address.com/',
                                sinds => []);

          # also good and well
          my $to = [ $baseuri . 'my-lovely-cat',
                     'http://subject-address.com/',
                      [] ];

          # better
          my $to = $tm->internalize ('my-lovely-cat' => 'http://subject-address.com/');

       To access the individual fields, you can either use the struct accessors "saddr" and
       "sinds", or use the constants defined above for indices into the array:

       Example:

          warn "indicators: ", join (", ", @{$to->sinds});

          warn "locator:    ", $to->[TM->ADDRESS];

   Methods
       internalize
           $iid  = $tm->internalize ($some_id)

           $iid  = $tm->internalize ($some_id => $some_id)

           @iids = $tm->internalize ($some_id => $some_id, ...)

           This method does some trickery when a new toplet should be added to the map, depending
           on how parameters are passed into it. The general scheme is that pairs of identifiers
           are passed in.  The first is usually the internal identifier, the second a subject
           identifier or the subject locator. The convention is that subject identifier URIs are
           passed in as string references, whereas subject locator URIs are passed in as strings.

           The following cases are covered:

           "ID => undef"
               If the ID is already an absolute URI and contains the "baseuri" of the map as
               prefix, then this URI is used as internal toplet identifier. If the ID is some
               other URI, then a toplet with that URI as subject locator is searched in the map.
               If such a toplet already exists, then nothing special needs to happen.  If no such
               toplet existed, a new URI, based on the "baseuri" and a random number will be
               created for the internal identifier and the original URI is used as subject
               address.

               NOTE: Using "URI => URI" implies that you use two different URIs as subject
               addresses. This will result in an error.

           "ID => URI"
               Like above, only that the URI is directly interpreted as subject address.

           "ID => \ URI" (reference to string)
               Like above, only that the URI is interpreted as another subject identifier. If the
               toplet already existed, then this subject identifier is simply added. Duplicates
               are suppressed (since v1.31).

           "undef => URI"
               Like above, only that the internal identifier is auto-created if there is no
               toplet with the URI as subject address.

               Attention: If you call internalize like this

                 $tm->internalize(undef => $whatever)

               then perl will (un)helpfully replace the required undef with the string "undef"
               and wreck the operation.  Using either a variable to hold the undef or replacing
               the (syntactic sugar) arrow with a comma works around this issue.

               Attention: If you call internalize like this

                 $tm->internalize(undef => $whatever)

               then perl will (un)helpfully replace the required undef with the string "undef"
               and wreck the operation.  Using either a variable to hold the undef or replacing
               the (syntactic sugar) arrow with a comma works around this issue.

           "undef => \ URI"
               Like above, only that the URI us used as subject identifier.

           "undef => undef"
               A toplet with an auto-generated ID will be inserted.

           In any case, the internal identifier(s) of all inserted (or existing) toplets are
           returned for convenience.

       toplet (old name midlet)
           $t  = $tm->toplet ($mid)

           @ts = $tm->toplet ($mid, ....)

           This function returns a reference to a toplet structure. It can be used in scalar and
           list context.

       toplets (old name midlets)
           @mids = $tm->toplets

           @mids = $tm->toplets (@list_of_ids)

           @mids = $tm->toplets ($selection_spec)

           This function returns toplet structures from the map. NOTE: This has changed from v
           1.13. Before you got ids.

           If no parameter is provided, all toplets are returned. This includes really everything
           also infrastructure toplets. If an explicit list is provided as parameter, then all
           toplets with these identifiers are returned.

           If a search specification is used, it has to be passed in as string reference. That
           string contains the selection specification using the following simple language (curly
           brackets mean repetition, round bracket grouping, vertical bar alternatives):

               specification -> { ( '+' | '-' ) group }

           whereby group is one of the following:

           "all"
               refers to all toplets in the map. This includes those supplied by the application.
               The list also includes all infrastructure topics which the software maintains for
               completeness.

           "infrastructure"
               refers to all toplets the infrastructure has provided. This implies that

                  all - infrastructure

               is everything the user (application) has supplied.

           Examples:

                # all toplets except those from TM::PSI
                $tm->toplets (\ '+all -infrastructure')

           NOTE: No attempt is made to make this list unique.

           NOTE: The specifications are not commutative, but are interpreted from left-to-right.
           So "all -infrastructure +infrastructure" is not the same as "all +infrastructure
           -infrastructure". In the latter case the infrastructure toplets have been added twice,
           and are then deducted completely with "-infrastructure".

       tids (old name mids)
           $mid  = $tm->tids ($some_id)

           @mids = $tm->tids ($some_id, ...)

           This function tries to build absolute versions of the identifiers passed in. "undef"
           will be returned if no such can be constructed. Can be used in scalar and list
           context.

           •   If the passed-in identifier is a relative URI, so it is made absolute by prefixing
               it with the map "baseuri" and then we look for a toplet with that internal
               identifier.

           •   If the passed-in identifier is an absolute URI, where the "baseuri" is a prefix,
               then that URI will be used as internal identifier to look for a toplet.

           •   If the passed-in identifier is an absolute URI, where the "baseuri" is NOT a
               prefix, then that URI will be used as subject locator and such a toplet will be
               looked for.

           •   If the passed-in identifier is a reference to an absolute URI, then that URI will
               be used as subject identifier and such a toplet will be looked for.

       externalize
           $tm->externalize ($some_id, ...)

           This function simply deletes the toplet entry for the given internal identifier(s).
           The function returns all deleted toplet entries.

           NOTE: Assertions in which this topic is involved will not be removed. Use
           "consolidate" to clean up all assertion where non-existing toplets still exist.

ASSERTIONS INTERFACE

       One assertion is a record containing its own identifier, the scope, the type of the
       assocation, an field whether this is an association, an occurrence or a name and then all
       roles and all players, both in separate lists.

       Assertions consist of the following components:

       lid (index "LID"):
           Every assertion has an identifier. It is a unique identifier generated from a
           canonicalized form of the assertion itself.

       scope (index: "SCOPE")
           This component holds the scope of the assertion.

       kind (index: "KIND", redundant information):
           For technical reasons (read: it is faster) we distinguish between full associations
           ("ASSOC"), names ("NAME") and occurrences ("OCC").

       type (index: "TYPE"):
           The toplet id of the type of this assertion.

       roles (index: "ROLES"):
           A list reference which holds a list of toplet ids for the roles.

       players (index: "PLAYERS"):
           A list reference which holds a list of toplet IDs for the players.

       canon (index: "CANON"):
           Either 1 or "undef" to signal whether this assertion has been (already) canonicalized
           (see "canonicalize"). If an assertion is canonicalized, then the players and roles
           lists are sorted (somehow), so that assertions can be easily compared.

       Obviously the lists for roles and players always have the same length, so that every
       player corresponds to exactly one role. If one role is played by several players, the role
       appears multiple times.

       As a special case, names and occurrences are mapped into assertions, by

       •   setting the roles to "thing" and "value",

       •   setting the players to the toplet id in question and using a TM::Literal as the player
           for "value",

       •   using the type component to store the name/occurrence type,

       •   using as kind either "NAME" or "OCC"

       Example:

          # general association
          $a = Assertion->new (type => 'is-subclass-of',
                               roles   => [ 'subclass', 'superclass' ],
                               players => [ 'rumsti',   'ramsti' ])

          warn $a->scope . " is the same as " . $a->[TM->SCOPE];

          # create a name
          use TM::Literal;
          $n = Assertion->new (kind    => TM->NAME,
                               type    => 'name',
                               scope   => 'us',
                               roles   => [ 'thing', 'value' ],
                               players => [ 'rumsti',
                                            new TM::Literal ('AAA') ]);

          # create an occurrence
          use TM::Literal;
          $n = Assertion->new (kind    => TM->OCC,
                               type    => 'occurrence',
                               scope   => 'us',
                               roles   => [ 'thing', 'value' ],
                               players => [ 'rumsti',
                                            new TM::Literal ('http://whatever/') ]);

   Special Assertions
       This package adopts the following conventions to store certain assertions:

       "is-subclass-of"
           Associations of this type should have one role "subclass" and another "superclass".
           The scope should always be "us".

       "isa"
           Associations of this type should have one role "instance" and another "class". The
           scope should always be "us".

       "NAME"
           Assertions for names should have the "KIND" component set to it and use the "TYPE"
           component to store the name type. The two roles to use are "value" for the value and
           "thing" for the toplet carrying the name.

       "OCC"
           Assertions for occurrences should have the "KIND" component set to it and use the
           "TYPE" component to store the occurrence type. The two roles to use are "value" for
           the value and "thing" for the toplet carrying the name.

   Methods
       assert
           @as = $tm->assert (@list-of-assertions)

           This method takes a list of assertions, canonicalizes them and then injects them into
           the map. If one of the newly added assertions already existed in the map, it will be
           ignored.

           In this process, all assertions will be completed (if fields are missing).

           If an assertion does not have a type, it will default to $TM::PSI::THING.
           If an assertion does not have a scope, it defaults to $TM::PSI::US.

           Then the assertion will be canonicalized (unless it already was). This implies that
           non-canonicalized assertions will be modified, in that the role/player lists change.
           Any assertion not having an LID will get one.

           The method returns a list of all asserted assertions.

           Example:

             my $a = Assertion->new (type => 'rumsti');
             $tm->assert ($a);

           NOTE: Maybe the type will default to association in the future.

       retrieve
           $assertion  = $tm->retrieve ($some_assertion_id)

           @assertions = $tm->retrieve ($some_assertion_id, ...)

           This method takes a list of assertion IDs and returns the assertion(s) with the given
           (subject) ID(s). If the assertion is not identifiable, "undef" will be returned in its
           place. Called in list context, it will return a list of assertion references.

       asserts
           @assertions = $tm->asserts ($selection_spec)

           If a search specification is used, it has to be passed in as string reference. That
           string contains the selection specification using the following simple language (curly
           brackets mean repetition, round bracket grouping, vertical bar alternatives):

               specification -> { ( '+' | '-' ) group }

           whereby group is one of the following:

           "all"
               refers to all assertions in the map. This includes those supplied by the
               application, but also all predefined associations, names and occurrences.

           "associations"
               refers to all assertions which are actually associations

           "names"
               refers to all assertions which are actually name characteristics

           "occurrences"
               refers to all assertions which are actually occurrences

           "infrastructure"
               refers to all assertions the infrastructure has provided. This implies that

                  all - infrastructure

               is everything the user (application) has supplied.

           Examples:

                # all toplets except those from TM::PSI
                $tm->asserts (\ '+all -infrastructure')

                # like above, without assocs, so with names and occurrences
                $tm->asserts (\ '+all -associations')

           NOTE: No attempt is made to make this list unique.

           NOTE: The specifications are not commutative, but are interpreted from left-to-right.
           So "all -associations +associations" is not the same as "all +associations
           -associations".  "-infrastructure".

       is_asserted
           $bool = $tm->is_asserted ($a)

           This method will return 1 if the passed-in assertion exists in the store. The
           assertion will be canonicalized before checking, but no defaults will be added if
           parts are missing.

       retract
           $tm->retract (@list_of_assertion_ids)

           This methods expects a list of assertion IDs and will remove the assertions from the
           map. If an ID is bogus, it will be ignored.

           NOTE: Only these particular assertions will be deleted. Any toplets mentioned in these
           assertions will remain. Use "consolidate" to remove unnecessary toplets.

       match, match_forall, match_exists
           @assertions = $tm->match (TM->FORALL [ , search-spec ] );

           @assertions = $tm->match (TM->EXISTS [ , search-spec ] );

           @assertions = $tm->match_forall ( [ search-spec ] );

           @assertions = $tm->match_exists ( [ search-spec ] );

           These methods take a search specification and return matching assertions. The result
           list contains references to the assertions themselves, not to copies. You can change
           the assertions themselves on your own risk (read: better not do it).

           For "match", if the constant "FORALL" is used as first parameter, this method returns
           a list of all assertions in the store following the search specification. If the
           constant "EXISTS" is used, the method will return a non-empty value if at least one
           can be found. Calling the more specific "match_forall" is the same as calling "match"
           with "FORALL". Similar for "match_exists".

           NOTE: "EXISTS" is not yet implemented.

           For search specifications there are two alternatives:

           Generic Search
               Here the search specification is a hash with the same fields as for the
               constructor of an assertion:

               Example:

                  $tm->match (TM->FORALL, type    => '...',
                                          scope   => '...,
                                          roles   => [ ...., ....],
                                          players => [ ...., ....]);

               Any combination of assertion components can be used, all are optional, with the
               only constraint that the number of roles must match that for the players. All
               involved IDs should be absolutized before matching. If you use "undef" for a role
               or a player, then this is interpreted as dont-care (wildcard).

           Specialized Search
               The implementation also understands a number of specialized search specifications.
               These are listed in TM::Axes.

           NOTE: Some combinations will be very fast, while others quite slow. If you experience
           problems, then it might be time to think about indexing (see TM::Index).

           NOTE: For the assertion type and the role subclassing is honored.

   Role Retrieval
       is_player, is_x_player
           $bool = is_player   ($tm, $assertion, $player_id, [ $role_id ])

           $bool = is_x_player ($tm, $assertion, $player_id, [ $role_id ])

           This function returns 1 if the identifier specified by the "player_id" parameter plays
           any role in the assertion provided as "assertion" parameter.

           If the "role_id" is provided as third parameter then it must be exactly this role (or
           any subclass thereof) that is played. The 'x'-version is using equality instead of
           'subclassing' ('x' for "exact").

       get_players, get_x_players
           @player_ids = get_players   ($tm, $assertion, [ $role_id ])

           @player_ids = get_x_players ($tm, $assertion, $role_id)

           This function returns the player(s) for the given role. If the role is not provided
           all players are returned.

           The "x" version does not honor subclassing.

       is_role, is_x_role
           $bool = is_role   ($tm, $assertion, $role_id)

           $bool = is_x_role ($tm, $assertion, $role_id)

           This function returns 1 if the "role_id" is a role in the assertion provided. The "x"
           version of this function does not honor subclassing.

       get_roles
           @role_ids = get_roles ($tm, $assertion, $player)

           This function returns a list of roles a particular player plays in a given assertion.

       get_role_s
           @role_ids = @{ get_role_s ($tm, $assertion) }

           This function extracts a reference to the list of role identifiers.

   Auxiliary Functions
       absolutize
           $assertion = absolutize ($tm, $assertion)

           This method takes one assertion and makes sure that all identifiers in it (for the
           type, the scope and all the role and players) are made absolute for the context map.
           It returns this very assertion.  It will not touch canonicalized assertions.

       canonicalize
           $assertion = canonicalize ($tm, $assertion)

           This method takes an assertion and reorders the roles (together with their respective
           players) in a consistent way. It also makes sure that the KIND is defined (defaults to
           "ASSOC"), that the type is defined (defaults to "THING") and that all references are
           made absolute LIDs. Finally, the field "CANON" is set to 1 to indicate that the
           assertion is canonicalized.

           The function will not do anything if the assertion is already canonicalized.  The
           component "CANON" is set to 1 if the assertion has been canonicalized.

           Conveniently, the function returns the same assertion, albeit a maybe modified one.

           TODO: remove map parameter, it is no longer necessary

TAXONOMICS AND SUBSUMPTION

       The following methods provide useful basic, ontological functionality around transitive
       subclassing between classes and instance/type relationships.

       NOTE: Everything is a subclass of "thing" (changed in v1.35).

       NOTE: Everything is an instance of "thing".

       NOTE: See TM::PSI for predefined things.

   Boolean Methods
       is_subclass
           $bool = $tm->is_subclass ($superclass_id, $subclass_id)

           This function returns 1 if the first parameter is a (transitive) superclass of the
           second, i.e. there is an assertion of type is-subclass-of in the context map. It also
           returns 1 if the superclass is a $TM::PSI::THING or if subclass and superclass are the
           same (reflexive).

       is_a
           $bool = $tm->is_a ($something_lid, $class_lid)

           This method returns 1 if the thing referenced by the first parameter is an instance of
           the class referenced by the second. The method honors transitive subclassing.

   List Methods
       subclasses, subclassesT
           @lids = $tm->subclasses  ($lid, ...)

           @lids = $tm->subclassesT ($lid, ...)

           "subclasses" returns all direct subclasses of the toplet identified by $lid. If the
           toplet does not exist, the list will be empty. "subclassesT" is a variant which honors
           the transitive subclassing (so if A is a subclass of B and B is a subclass of C, then
           A is also a subclass of C).

           Duplicates are suppressed.

       superclasses, superclassesT
           @lids = $tm->superclasses  ($lid, ...)

           @lids = $tm->superclassesT ($lid, ...)

           The method "superclasses" returns all direct superclasses of the toplet identified by
           $lid. If the toplet does not exist, the list will be empty. "superclassesT" is a
           variant which honors transitive subclassing.

           Duplicates are suppressed.

       types, typesT
           @lids = $tm->types  ($lid, ...)

           @lids = $tm->typesT ($lid, ...)

           The method "types" returns all direct classes of the toplet identified by $lid. If the
           toplet does not exist, the list will be empty. "typesT" is a variant which honors
           transitive subclassing (so if a is an instance of type A and A is a subclass of B,
           then a is also an instance of B).

           Duplicates will be suppressed.

       instances, instancesT
           @lids = $tm->instances  ($lid, ...)

           @lids = $tm->instancesT ($lid, ...)

           These methods return the direct ("instances") and also indirect ("instancesT")
           instances of the toplet identified by $lid.

           Duplicates are suppressed.

   Filters
       Quite often one needs to walk through a list of things to determine whether they are
       instances (or types, subtypes or supertypes) of some concept. This list of functions lets
       you do that: you pass in a list (reference) and the function behaves as filter, returning
       a list reference.

       are_instances
           @id = $tm->are_instances ($class_id, @list_of_ids)

           Returns all those ids where the topic is an instance of the class provided.

       are_types (Warning: placeholder only)
           @ids = $tm->are_types ($instance_id, @list_of_ids)

           Returns all those ids where the topic is a type of the instance provided.

       are_supertypes (Warning: placeholder only)
           @ids = $tm->are_supertypes ($class_id, @list_of_ids)

           Returns all those ids where the topic is a supertype of the class provided.

       are_subtypes (Warning: placeholder only)
           @ids = $tm->are_subtypes ($class_id, @list_of_ids)

           Returns all those ids where the topic is a subtype of the class provided.

REIFICATION

       is_reified
           ($tid) = $tm->is_reified ($assertion)

           ($tid) = $tm->is_reified ($url)

           In the case that the handed-in assertion is internally reified in the map, this method
           will return the internal identifier of the reifying toplet. Or "undef" if there is
           none.

           In the case that the handed-in URL is used as subject address of a toplet, this method
           will return the internal identifier of the reifying toplet. Or "undef" if there is
           none.

       reifies
           $url       = $tm->reifies ($tid)

           $assertion = $tm->reifies ($tid)

           Given a toplet identifier, this method returns either the internally reified
           assertion, an externally reified object via its URL, or "undef" if that toplet does
           not reify at all.

VARIANTS (aka "The Warts")

       No comment.

       variants
           $tm->variants ($id, $variant)

           $tm->variants ($id)

           With this method you can get/set a variant tree for any topic. According to the
           standard only basenames (aka topic names) can have variants, but, hey, this is such an
           ugly beast (I am digressing). According to this data model you can have variants for
           all toplets/maplets. You only need their id.

           The structure is like this:

             $VAR1 = {
               'tm:param1' => {
                 'variants' => {
                   'tm:param3' => {
                     'variants' => undef,
                     'value' => 'name for param3'
                   }
                 },
                 'value' => 'name for param1'
               },
               'tm:param2' => {
                 'variants' => undef,
                 'value' => 'name for param2'
               }
             };

           The parameters are the keys (there can only be one, which is a useful, cough,
           restriction of the standard) and the data is the value. Obviously, one key value (i.e.
           parameter) can only exists once.

           Caveat: This is not very well tested (read: not tested at all).

LOGGING

       The TM module hosts (since 1.29) the Log4Perl object $TM::log. It is initialized with some
       reasonable defaults, but an using application can access it, tweak it, or overwrite it
       completely.

SEE ALSO

       TM::PSI, Log::Log4perl

COPYRIGHT AND LICENSE

       Copyright 200[1-8] by Robert Barta, <drrho@cpan.org>

       This library is free software; you can redistribute it and/or modify it under the same
       terms as Perl itself.