TM One Language (to rule them all)

Recently Dmitry made some remarks which got me thinking that we do not have yet the correct approach to the property issue:

Properties are a universal mechanism that can be used for many purposes. One of them is mapping from TMDM representation to "nice" CTM representation. RDF mapping is another one. Mapping to object oriented languages is also simplified with properties.

It is definitely true that - if we had an explicit property concept in TM - a lot of the problems would go away, or at least can be directly addressed. Instead of mucking around.

Enter TMOL

So let us assume for a moment that we had a TM ontology language (TMOL), and that that would allow us to define properties:

is-employed isa tmol:property
tmol:implying:  """
  employment (employee: $_left
              employer: $at,
              position: $as)

employs isa tmol:property
tmol:implying: """
  employment (employee: $_right,
              employer: $_left,
              position: edutainer)

The tmol:property is a well-defined concept in TMOL. We will return to it later.

The CTM Connection

Then - as Dmitry so correctly points out - CTM can profit directly, in that we can use properties in the same way as we now use templates:

rho is-employed at arcs as semantosoph .

tu-vienna employs rho .

Both would use the above property definitions to expand the shorthand into the full-blown association of type employment. That is purely mechanical.

And that process also works the other way. So if we had to serialize the topic rho into CTM, then a TMOL-aware processor could find the pattern(s) matching the associations and would create

rho is-employed at arcs as semantosoph .

rho is-employed at tu-vienna as edutainer .

If the CTM deserializer is unaware of TMOL or the particular property definitions, then it would just spit out canonical CTM.

The RDF Connection

If we had to transliterate TM content into RDF(S), then property definitions can be used to guide this process.

Without any of these, an TM2RDF converter would use one of the generic ways to convert an association into a set of RDF triples. But a TMOL-aware converter can use the property definitions, do a pattern match and produce:

rho is-employed [ isa employment,
                  at  arcs,
                  as  semantosoph ];
                [ isa employment,
                  at  tu-vienna,
                  as  edutainer ] .

This is not the end of the rope. More can (and has to) be done in this area.

Converting RDF into TM can also benefit. Confronted with an RDF fragment

rho is-employed [ at arcs, as semantosoph ] .

then - similar to the CTM deserializer - one of the patterns may trigger and may create a decent association.

The TMQL Connection

Dmitry again:

With TMQL (not in the current version, in theory) , ... it would be possible to use paths ...

To align this with our running example (and bending the syntax to avoid clashes), this could turn out as:

rho <-> is-employed

A non-TMOL-aware processor would report an error here, but one which understands TMOL would recognize is-employed as property. And that would cause it to expand that query expression into

rho <- employee       # because of the $_left
    [ ^ employment ]  # because of the assoc type
    -> *              # for all outgoing topics
    -- rho            # except where we came from

That is a purely syntactic transformation. No need to change anything in the TMQL semantics.

TMQL and Transitivity

You may have glanced over my recent rant where I lamented about a legitimate TMQL feature request. In short, people may want to write

rho <<- is-located-in * ->>

indirectly expressing that is-located-in is transitive. Or use

some_work <<- is-responsible | has-adopted ->>

indirectly saying that is-responsible and has-adopted mean the same thing here.

Now, with a TMOL you could actually say what you intend more directly:

is-located-in isa tmol:transitive-property
tmol:implying: .....

and simply use in TMQL

rho <-> is-located-in

That's it. Again no need to extend TMQL. Also the second TMQL example using alternatives can be rewritten into something more eye-pleasing:

some_work ( <-> is-responsible ||
            <-> has-adopted    )

TMOL Agenda

Of course, TMOL should be able to do much more, being designed as ontology language.

I am currently in the process to collect ideas and requirements, some of which are:

  • reintroducing functions and predicates (like those in earlier TMQL drafts)
  • more RDF/OWL transliteration support,
  • use of CWA, instead of OWA (may conflict with OWL)
  • classes and control over their disjointness,
  • properties and transitivity and symmetry
  • maybe explicit space concepts (containment, and such),
  • maybe explicit time concepts (after, before, since, ....)

Drop me a note if you have something burning under your fingernails.

Work supported by the Austrian Research Centers.

Posted In