[sc34wg3] Question on TNC / Montreal minutes

[Marc de Graauw]

* Marc
| So one mechanism had to go.

* Lars
| Why? Surely there can be more than one way to establish identity
| without this counting as redundancy?

Yes.
In fact, as a former relational database administrator (there I go again...) I
think having "alternate keys" is perfectly alright. The problem here is the
same thing (the data element 'CustomerName') is used twice as a key, and I
don't think that is right.

* Marc
| (We could of course use PSI's which are not published on the WWW,
| but to me that sounds suspiciously much like using names and
| disguising them as PSI's.)

* Lars
| It's precisely what it is (except that it is not limited to names).
| It's just that URI have none of the problems that plague merging by
| name.

This would lead to the same problems which are inherent in names. When we have
a name (say "Marc de Graauw") and we use this route, you could make the
following PSI: http://psi.mynames.org#MarcdeGraauw and I could make
http://psi.mynames.org#Marc-de-Graauw . So I do not think using this route is
viable unless you also have a standard for translating names to URI's (and I
do not think we should go there). As you can see I am not blind to the
problems involved in using names as identifiers, but just making them URI's
doesn't solve all those problems.

| I'm sorry, but so far I've only seen an argument for why the TNC is
| useful.

Thank you.

| I think merging by name is useful, but that the TNC is not.

I do not think the TNC should remain as is, it should be optional. But just
having "merging by name" alone will not do. If you have an application were
you want to merge by name (in a particular namespace), you will also want to
ensure names are unique (in that particular namespace), and you will want the
TM processor to check that for you. Which means making a namespace, which
means applying the (optional) TNC _for that particular namespace_.

| What we really need is a more general mechanism for doing merging by
| topic characteristics

I would applaud that. What is actually needed is a way to say a topic
characteristic (within a scope) is an (alternate) key for a topic. A "Topic
Characteristic Constraint" (optional of course).

| in a manner specified by an individual
| application and independent of each topic map used by that
| application.

Maybe. Maybe not. I'm not convinced yet. Until now I would like that
alternate-key-mechanism in the standard, and in the TM itself, not a TMCL
schema. Maybe if I take a closer look at the TMCL proposals I change my mind.

Marc