[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:
http://kill.devc.at/node/131
[ reproduced below for your convenience ]
\rho
------------------------------------------------------------------------
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
mechanical.
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
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 [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
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 [9]Austrian Research Centers [4].
Let evolution finish its work.
_________________________________________________________________
Source URL (retrieved on 02/25/2008 - 10:22):
[10]http://kill.devc.at/node/131
Links:
[1] http://www.subjectcentric.com/
[2]
http://www.isotopicmaps.org/pipermail/sc34wg3/2008-February/003710.htm
l
[3] http://kill.devc.at/node/128
[4] http://www.arcs.ac.at
References
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