[sc34wg3] New syntax for (binary) associations

Robert Barta rho at devc.at
Mon Feb 25 03:25:17 EST 2008

On Thu, Feb 07, 2008 at 09:41:37AM -0800, Dmitry wrote:
> On Thursday, February 07, 2008, at 05:21AM, "Lars Heuer" <heuer at semagia.com> wrote:

> >But how is that different from defining a template (in the CTM
> >context)?

> 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. Properties
> can simplify TMCL and TMQL.


I think Dmitry is hitting the right spot. After analyzing TMCL, OWL
and more thinking I came up with this idea:


[ reproduced below for your convenience ]


TM One Language (to rule them all)

   Recently [6]Dmitry [1] made [7]some remarks [2] 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

   And that process also works the other way. So if we had to deserialize
   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

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

   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 [8]recent rant [3] 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

     * 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 [9]Austrian Research Centers [4].

   Let evolution finish its work.

   Source URL (retrieved on 02/25/2008 - 10:22):

   [1] http://www.subjectcentric.com/
   [3] http://kill.devc.at/node/128
   [4] http://www.arcs.ac.at


   1. http://kill.devc.at/
   2. http://kill.devc.at/taxonomy/term/43
   3. http://kill.devc.at/taxonomy/term/34
   4. http://kill.devc.at/taxonomy/term/23
   5. http://kill.devc.at/taxonomy/term/22
   6. http://www.subjectcentric.com/
   7. http://www.isotopicmaps.org/pipermail/sc34wg3/2008-February/003710.html
   8. http://kill.devc.at/node/128
   9. http://www.arcs.ac.at/
  10. http://kill.devc.at/node/131

More information about the sc34wg3 mailing list