[sc34wg3] Question on TNC / Montreal minutes

[Lars Marius Garshol]

* Marc de Graauw
|
| 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.

I see what you mean, and I agree. It would be right if there were a
subject indicator that you were actually pointing at, since the two
data items would then be providing different (and independent!)
information.

TMCL would put this right, of course.
 
* Lars Marius Garshol
|
| [non-resolving subject indicators like names?]
|
| 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.
 
* Marc de Graauw
|
| 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. 

That wouldn't happen if people follow correct procedure, since
mynames.org will only be owned by a single authority, and if that
authority includes both you and me we should coordinate before
publishing PSIs there. If we don't we will richly deserve all the
misery that will inevitably result.

The problems the URI approach avoids are:

 - people screwing up with capitalization, whitespace, punctuation
   etc.,

 - recursive notions of identity (using name types to control TNC
   merges would make this less severe), and

 - having to build volatile identity into the core standard and thus
   into APIs where it is *very* hard to get this to work reasonably.
   Merge by URI can be made to work, but TNC merge (and similar
   things) is just awful.

| 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). 

This is how we currently use merge-by-name. The autogeneration
procedure builds subject identifiers from names by normalizing the
name and inserting the resulting string into a URI template. The
template chosen defines the namespace and it makes the merging much
more effective than a simple merge-precise-strings.

| 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.

Not all problems, no. What it does mean is that you avoid the
undesired merges, which is the key problem.
 
| 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. 

Absolutely, and then you will probably want one of two behaviours: the
processor should either flag uniqueness violations or silently merge
the offenders. Another argument for why this belongs in TMCL.

| Which means making a namespace, which means applying the (optional)
| TNC _for that particular namespace_.

So you still want to tie it to particular scope? What about the
argument that's been put forward against that, that people may use the
same scope in different ways?
 
* Lars Marius Garshol
|
| What we really need is a more general mechanism for doing merging by
| topic characteristics
 
* Marc de Graauw
|
| I would applaud that. 

Good. :)

| What is actually needed is a way to say a topic characteristic
| (within a scope) is an (alternate) key for a topic. 

Yes. And one may choose to disregard the scope.

| A "Topic Characteristic Constraint" (optional of course).

Yes, it would be something people either put into their schema, or
don't put in.
 
| 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.

I fear the current TMCL proposals will do nothing of the kind, since
none of them have this feature.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >