[tmcl-wg] Consistency of TMCL Schemas ?

[Bernard Vatant]

Lars Marius, I just said I would not post here any more, but you made me
change my mind. Thanks for that.

> * Bernard Vatant

> | For now, I meant simply that OWL can express a lot of things TMCL is
> | intended to do, and I am not and will certainly not be the only one
> | to explore that path, and use it that way.
>
> I agree completely with that. There is an overlap and we need to
> figure out what to do about it. I think it's also clear that simply
> saying "we'll adopt OWL as-is and turn TMCL into a description of how
> to use OWL in topic maps" won't be enough.

Certainly it won't be enough. But we'll know what is lacking when we have
tried it.

> | People will certainly want to find at least features found in OWL,
> | and that's why I was pointing at internal consistency of TM schemas,
> | among other needed features.
>
> I think internal consistency might be a reasonable requirement for
> TMCL, though I'll leave that for the editors to judge.

Thanks for agreeing on that.

> | And another concern is that it seems to me that TMCL is aiming at a
> | high level of expressivity requirements, maybe against usability.
> | And yes, I have a concern about the pace of TMCL development, and
> | the high level of requiremnts will not help. I know what the reasons
> | are, but I am really afraid that if TMCL comes too late on the scene
> | and is too complex, it will have hard time to be adopted.
>
> I think your concerns are entirely reasonable, and in fact I share
> them. I think the only thing we can do is make sure TMCL isn't too
> complex, and that we get it out as soon as we can. There's not really
> all that much else to do or say, I think, at least not right now.

OK

> | Have you any idea of when it will happen?
>
> Ask the editors. (We already have a strawman, though. Comments on that
> would be helpful.)

I'll try to make some ...

> | 2. OWL is *not* another RDFS vocabulary. It's an ontology language
> | that happens to use the RDF syntax and data model. The main interest
> | of it is the expressivity of its abstract model, not the RDF
> | representation (which is maybe more of a drawback than anything
> | else.)
>
> That's an interesting take on it. OWL certainly is expressed as an RDF
> vocabulary, but I agree that that doesn't mean you *must* use RDF to
> be able to use it. As I argued in my paper large parts of OWL can be
> used in topic maps (with XTM syntax and all) right now. (Also, as I
> argued, some parts of OWL are unnecessary in topic maps.)

Then we are closer than I thought.

> I think the main mistake is to assume that OWL is not being taken into
> account. I also think that TMCL and OWL may be more different than you
> think.

Certainly, they will be built on different data model.

> I think the following might be the best solution:
>
>  - create a TMCL that handles constraints on topic maps, kind of like
>    RDFS and constraint parts of OWL, and
>
>  - reuse the ontology parts of OWL that make sense in topic maps as a
>    separate specification.

What do you mean by "constraint parts" and "ontology parts" of OWL,
exactly?

> The reuse might take the form of expressing OWL in topic maps pretty
> much the way an OWL schema would look if converted to topic maps using
> the Ontopia RDF->TM mapping vocabulary, or it might be reengineered
> somewhat (new URIs, for example), but include a simple and clear
> description of how to map RDF OWL to TM OWL.

So you are open to the notion of TM OWL (or OWL-TM) as a specific OWL
vocabulary. I'm not sure if it should be grounded on a lower level RDF ->
TM mapping, though.

> * Bernard Vatant
> |
> | So far, I've been quite happy with OWL expressivity for constraining
> | topic maps.
>
> * Lars Marius Garshol
> |
> | What do you mean by "topic maps" in this case? RDF?
>
> * Bernard Vatant
> |
> | I suppose I have to take this remark as being deliberately
> | provocative, and I won't answer to it.
>
> No, I mean it quite literally. It's not really possible to understand
> how you use OWL without knowing what kind of data model you are using
> it to constrain. If you use RDF then it's clear how you are doing it.
> If you use topic maps then it's not at all clear how you do it, and
> I'd be interested to hear it.

It's definitely topic maps constructs that are constrained this way,
namely:

- Allowed classes of topics, and class-subclass relationships
- Allowed association types and role types
- Constraints linking association type, role type and class of role player
(including cardinality)
- Constraints on occurrence type for a topic class (including cardinality)

Constraints on other TM features are not addressed yet, including scope.
Maybe they can't, and will need specific language. But there is already a
lot you can do with the above, and it can be a good start for
interoperability platform, since you can interpret this way features in a
"native" OWL ontology (not intended for TM) and make your TM "commit" to
them.

BTW I've submitted a paper on this subject for XML Europe, and if it's
accepted, we'll have a chance of discussing it in Amsterdam (around a
beer).

> And if you use something else that's similar to RDF and similar to
> topic maps, but not really 100% like either, well, then that would be
> useful to know, too, although then the reply to how you use OWL would
> probably be less useful, since nobody else would be in exactly the
> same position.

Agreed, and actually, there are a few bits of OWL that we will apply
specifically to Mondeca ITM data model and that are irrelevant to TMDM,
like for example representation of our structured "data items", which are
neither XML Datatypes nor XTM occurrences, actually.

> | There is one thing I will agree with you anyway. I wonder why I
> | posted here, and will refrain to do it any more.
>
> Why not? Because I asked you whether you were using topic maps or RDF?
> What was it I said that was so bad? (Reply off-list if you prefer.)

Well, I honestly took the question as provocative. Sorry about that.

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