[tmcl-wg] Consistency of TMCL Schemas ?

[Bernard Vatant]

Hello Dmitry

Thanks for biting the bait :))

> Firstly, I think that OWL and TMCL have different goals. Because of
> that priorities and preferences are different. It seems to me that OWL
> is concentrated on providing web oriented platform for automatic
inference
> in area that can be covered by Descriptive Logic.

I'm generally more interested in what a tool can actually achieve than in
what it was intended for. Our experience with topic maps so far is that
real-world effective applications are quite far from what they were
intended to: they were supposed to support general semantic
interoperability, and what we see (or in fact don't see most of the time
because the most effective applications are not public) are customized
applications running in companies intranets. My hunch is that it could be
quite the same with OWL. And this is not particular to our technologies.
Great achievements come most of the time from tool subversion :))

And DL is a limit for OWL-DL only. If you're bothered by that, use
OWL-Full.

> Because of that OWL has limited abilities to
> represent domain constraints and detail constructs for expressing
> relationships between classes.

Well, I'm not sure what you mean here, maybe you could show some of those
limits. So far, I've been quite happy with OWL expressivity for
constraining topic maps. And having too much expressivity is not a goal per
se, there is a trade-off between expressivity and usability. And in this
very case, between expressivity and interoperability. There is a *huge*
legacy being migrated right now into OWL. Look at bio-sciences for example.

> TMCL, from my perspective, has three main goals:
> - define what kind of information is expected to know about topic of
> specific type

OWL : Define properties attached to a domain defined by a class of topics
...

> - provide some boundaries for filling in expected information
> (cardinality, min/max values, type constraints etc)

OWL : Define restrictions on the properties on a given domain

> - define set of (may be complex) constraints which instance topic map
> has to be validated against.

OWL : Declare ontology a topic map is committed to

> I call them schema + validation goals.

You can call them an ontology and live with it ...

>  From user perspective it means that TMCL will allow:
> - build "smart" user interfaces which help users to view/create/modify
> topic map instances.

The problem of interfaces is orthogonal to validation IMO.

> - be sure in  quality  of  topic map instance before/during/after
> processing it.

Yes

> Because of that TMCL needs more powerful constraint language and has
> less requirements for detailed  class definitions.

Is a class definition something else than definition of constraints on
properties ?

> Secondly, TMCL and OWL rely on different data models or probably,
> better to say, they use different categories to create models.
> I can imagine rewriting OWL to make it compatible with Topic Maps set
> of categories (such as names, occurrences, associations, subject
> identifiers). But, I think, it will be actually much more complicated
> than existing OWL.

I'm not sure of what you mean by "rewriting OWL".

> I personally see possibility in creating tools which will map/translate
> OWL ontologies into TMCL schemas. Some information can be lost
> (detailed class relationships, for example) during this translation.
> But most of information will be preserved and mapped to TM-compatible
> view. On the other hand I think that TMCL authors will prefer to extend
> OWL-mapped to TMCL- Schemas with additional constraints which are not
> (naturally) expressible in OWL.

Agreed. That's why we need to see the limits of OWL, what can be achieved
with it, and what is lacking. That's what we explore in Mondeca right now.
And actually, so far, we have found OWL very convenient to express almost
whatever we wanted to express at the knowledge model level at least
(topic-role-association structures). There are some issues at the data
level, yes.

> Actually, "R8 Merging of schemas" mentioned ability to identify
> conflicts in schemas which I personally prefer to see in a relaxed
> form.

It's not only a question of merging, unless you consider putting
constraints together to build a schema as a case of merging - which it is,
actually. But my point is that TMCL should provide support for this merging
to be a logical process, because a constraint is AFAIK nothing but a
logical rule. Checking for consistency seems to me a minimal requirement
when you put rules together. But maybe I'm biased by my maths background
...

> I think  we would like to represent complex constraints using TMCL. And
> in this case we can not require automatic schema consistency checking.
> I think, TMCL Lite which will have limited constraint language  may
> support some form of schema consistency checking.

Might be. Seems to me that the distinction TMCL Lite - TMCL Big is too much
similar to OWL Lite - OWL Full not to explore this parallel.

> I personally think that schema consistency checking is a "helper"
> function of software tools. I look at schema creation as a creation of
> some theory in natural science. Some theory features can be checked on
> internal consistency. But what is more important is checking schema
> against real samples, and try to find samples which invalidate existing
> schema. Contradictions are resolved by refining schema. At some point
> schema become more or less stable. Core of the schema is not modified
> anymore. But peripheral constraints are refined over all schema live
> time. If some of the steps in "theory" creation/refining can be
> supported by software at some level it is good.

I could agree with that in theory. I'm waiting to see it in practice :))

> And... I would probably look at more robust inference mechanism than
> Descriptive Logic. This inference mechanism must have ability to assert
> exceptions and have ability to reason with contradictory arguments.
> These kind of things that CYC/OpenCYC can do now (and may be beyond
> that).

Well, maybe. But currently I'd like to pick low-hanging fruits, for what I
see now in real world applications, there is a huge demand for more simple
things. There is a lot indeed in Cyc. What I wonder is who will use such a
complexity. There again, the trade-off between usability and expressivity
is to be considered.

Bottom line : I tend to try and integrate and make interoperable
(imperfect) tools available, known and used today, than waiting for the
perfect tools of tomorrow (or the day after).

Bernard

Bernard Vatant
Senior Consultant
Knowledge Engineering
Mondeca - www.mondeca.com
bernard.vatant@mondeca.com