[sc34wg3] 4.3 Constraints

[Lars Marius Garshol]

* Lars Marius Garshol
|
| Well, the thinking is that *every* topic map standard will follow
| the DM, and that if it doesn't it won't be a topic map standard, but
| something else. Also, I don't think such a declaration will be of
| much use if you don't trust the authors to be able to follow the DM,
| since then you can't trust the declaration either.

* Patrick Durusau
| 
| Well, does the same reasoning apply to an application that performs
| merger in ways not specified by the data model? Does that make it
| "something else?"

Well, an application is clearly something that by its very nature is
entirely different from a topic map standard. Still, I think having
applications that do merging in other ways than what the DM requires
is perfectly OK.

We have for example written a web-based topic map editor for a
customer where the user can, when editing one topic, search for topics
to merge into it, pick one and then merge it in. This is merging in a
case where the DM does not require a merge. Also, the merge is
slightly different from DM merge, since the name and description of
the merged-in topic are lost.

IMHO there is nothing wrong with this.

What would be wrong would be an XTM processor that did merging beyond
what XTM+DM required or less than XTM+DM required. But then it
wouldn't conform to ISO 13250-3 anyway, and so we would be covered.


The problem with issues like these are how to draw the boundary
between conformant and non-conformant. The DM is clear, but how to
connect a specific piece of software to the DM is not clear. 

Imagine an application where a distributed staff of authors edit topic
maps (maybe for an encyclopedia) all at the same time. The application
does no automated URI-based merging, but once a week the editor staff
sits down and uses a special report that shows them the URI-rule
violations, which they then resolve (by merging, by URI changes, or
whatever).

Is this a conformant application? I don't know, and even if we managed
to work it out in this case, there's going to be lots and lots of
boundary cases where the vendor may claim one thing and we claim
another. We'll never have a completely black/white picture here. For
XTM we can, because how to connect the real world to the standard is
clear in this case. For the DM it can't be.
 
| I really do think that for many purposes, including standards, the
| data model is a good thing. My concern is for cases, some have been
| mentioned on the list, where user requirements seem to be straining
| the standards that will (eventually) be based on the data model.

Let's get those on the table then, and discuss what to do with them.
 
| What do we tell users who sincerely think that their data models
| cannot be fitted into the TM data model?

That depends on what the users are actually doing. I can imagine a
whole range of answers for different cases.
 
| Make no mistake, I think having a standard for implementing topic
| maps, even if it is only our current view of how that should be
| done, is a very important thing. And that standards, such as
| constraint and query languages, of necessity must be based upon an
| implementation view of topic maps. Would be hard to imagine
| otherwise.

We agree here. I don't see what else a standard could do, really.
 
| Take a fairly likely senario within the DM governed standards: The
| TMDM is post FDIS as 13250-2. We are all (still) working on TMQL
| when we discover the need for something that was not included in
| 13250-2.  We want to be conformant with 13250-2 but we have to add
| something in TMQL, which of necessity makes us out of conformance
| with 13250-2. Are we then working on a non-topic map standard? I
| would say no and suspect you would agree.

I don't think that case would arise. We can't let TMQL query something
that is not in topic maps. The only choices left for us would in that
scenario would be to extend TMDM (and maybe XTM) to accomodate this,
or to leave the feature out.

How do you make TMQL query the names of association roles when
association roles have no names? (Ignore reification for the sake of
the argument, please.) I don't see how you can, and even if you did
how would people get association role names into their topic maps?
We'd have to extend XTM, but that alone wouldn't be enough, since
there would be no clear definition of how the XTM extension related to
what TMQL is querying.

So I really don't see this happening.

| [constraints in TMDM]
| 
| Well, that's certainly helpful. ;-) 

The sixth occurrence of the word "constraint" in the current TMDM
draft is the constraint at the end of 5.2. Not very hard to find.
 
| What I was looking for were statements to the effect that "one must
| implement ...." etc. In other words, what if I draft a standard for
| PSI's that does not have associations? Are topic maps required to
| have associations? Does that omission make my standard a non-topic
| map standard?
| 
| I was reading "allowed instances of the model" to mean that somewhere
| there was a definition of how much of the model or in what
| combinations it could be implemented. And still conform to the TMDM.

No, "allowed instances of the model" is talking about what
combinations of topic map items, topic items, property value
assignments, and so on are acceptable. For example, you're not allowed
to have the same source locator for a topic name and an association
role.

The current TMDM draft has no conformance section (because the editors
don't think it makes any sense to have one), so what you are looking
for is not there.

However, if you were to leave associations out of your TM engine you
would be unable to implement XTM correctly, and that is where
conformance comes in. You couldn't claim conformance to XTM.

And if you managed to somehow emulate associations with occurrences
(using clever tricks to infer association roles, and distinguish
associations from occurrences) so that you got the XTM test suite to
pass then, well, you would have a conformant XTM implementation (and a
solution for people wanting to use associations in the engine).

Now, this solution might be horrible to use, but that's neither here
nor there. The software is either conformant or not, and if it is then
it's up to the users to decide whether they like it or not, having
satisfied themselves that it is conformant.

(BTW: "A standard for PSIs that does not have associations" makes no
sense. PSIs don't *have* associations. Not that I think that really
affects your argument to any great extent.)

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >