TM One Language (to rule them all)
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.
So let us assume for a moment that we had a TM ontology language (TMOL), and that that would allow us to define properties:
employment (employee: $_left
employs isa tmol:property
employment (employee: $_right,
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:
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 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:
as semantosoph ];
[ isa employment,
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
then - similar to the CTM deserializer - one of the patterns may trigger and may create a decent association.
The TMQL Connection
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:
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
[ ^ 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
indirectly expressing that is-located-in is transitive. Or use
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:
and simply use in TMQL
That's it. Again no need to extend TMQL. Also the second TMQL example using alternatives can be rewritten into something more eye-pleasing:
<-> has-adopted )
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.