[sc34wg3] Alignment of N0396 with N0393

[Lars Marius Garshol]

* Jan Algermissen
|=20
| I think that this alignment has been requested by the N0396ers, yes?

Absolutely, but the RM-ers seemed to be thinking we should no longer
do this alignment the way it was originally planned. On the other hand
they haven't been very clear on what they want, so I was trying to see
if I could get some more clarity through the answer to this question.

| My intend was clarification and advancement of both 'camps'.

That makes sense. I was trying to ask all of you rather than just you,
Jan, but, well, I suppose I wasn't very clear about it.
=20
| Yes, I forgot bullet point 4, but that is just another merging rule
| to be added.

Maybe. One of my unanswered questions is whether or not N0393 allows
additional merging beyond what is required by SIDPs.
=20
| The issue with the [reifier] property (point 5) isn't an issue,
| because the [reifier] and [reified] properties are obsolete when the
| SAM is based on N0393. There is only one surrogate for a single
| subject anyway.

That might be, but I would check it before assuming it is the case. We
specify that additional rule because in the SAM it *is* needed,
despite the property being redundant in the sense that it can be
computed from the others.
=20
| [base name merging]
|
| This requires a lot of ASCII art and I don;t have the time to do
| that now. Will do as soon as I can.
=20
I understand. Do it when you can.

| [assertions !=3D associations]
|=20
| Well, it is a constraint imposed on assertions, but the structure is
| identical besides that.

It's not much help that they are the same besides that, because that's
a crucial difference. It means that the very common use case of
symmetric associations cannot be represented directly. The structure
of assertions in the RM is *not* the same as the structure of
associations in the SAM, and that means you can't model associations
with assertions without accounting for that problem.
=20
| I did not include the mapping of multiple players of a role to a
| single player (that is the set) for purposes of clarity. I expected
| you to 'find' this lapsus though ;-)
|=20
| The solution is in my reply top Dmitry.

There you propose two different approaches, one of which is clearly
invalid in the general case. The other may work, though to me the
whole constraint and the contortions you have to go through to deal
with it nonsensical. Note that I say it "*may* work". It's not clear
to me that this is acceptable, and a full version of N0406 would have
to account for this. Only when it does can we see whether it works.
=20=20
* Lars Marius Garshol
|
| I'm not sure if it does so correctly, but obviously it does try to
| say that scope only applies to topic names, occurrences, and
| associations.  (When you add variants it will apply to those as
| well.) The SAM handles this through the formalism, by specifying a
| property on certain item types.
=20
* Jan Algermissen
|
| Surely the XML will eventually have to include machine processable
| constraints, but, uh, should I have made the effort to develop them
| for this illustrative syntax?
|=20
| Or do you think it cannot be done at all?

What I am saying is that you people (note: plural) keep writing about
this XML DTD as if it were machine-processable, or nearly so, when in
fact it is nothing of the kind. Of course it can become so in the
future, but in the future anything can happen.

* Lars Marius Garshol
|
| Compare the documents, then. How hard do you think it is to
| understand N0396, compared to understanding N0393 and N0406?
=20
* Jan Algermissen
|
| I am not sure. It took me quite a while to *really* understand
| N0396, (what the reasons for certain design choices are, etc.)

A week or two seems reasonable to me, which it appears is what you
spent on it.
=20
| Given that there were/are still quite a few wrong/unprecise pieces
| of prose in N0396 and noone is asking questions about it, I wonder
| how many people did really read and understand it.
|=20
| In other words: the fact that noone objects to it, doesn't imply it
| is clear.

That's obviously true, but unless people do object or give us reason
to think that something is wrong there's not a whole lot we can do
about it, is there? I've had a number of implementors and would-be
implementors read through it[1], some of which have been in the
business for a long time and some of which used this as their
introduction to topic maps. None of them had serious problems with it,
and the problems they did report have been fixed.

You had a list of questions about the document, none of which found
any problems beyond simple prose adjustments, and none of which forced
us to rethink anything. To me that indicates that the thing really is
quite firm.

Personally, I would think that this is not very surprising. The thing
builds on all the work that went into XTM and quite a few of the
insights that appeared afterwards, it is based on experience with
several topic map engine implementations, and it uses a formalism that
was already familiar and established. The document has remained very
stable over two whole years and has been discussed in excruciating
detail at ISO meetings and elsewhere. So very little new work was
really done, and what has been done has been very carefully examined.

Given all this, what more do you think we should do? If you have
problems with the text, please report them. If you don't the thing
will probably go forward with what you perceive as problems in it.
There's nothing I can do about that, except stop to wait in the hope
that someone will in the end bother to report a problem I don't know
what is, and don't know whether really *is* a problem.
=20
* Lars Marius Garshol
|
| As for "processed by software" I think you will have to wait a while
| for software that can read a sentence like
|=20
|   "Values are equal if the first strings of the pairs are byte
|   identical and the second strings of the pairs are byte identical."
=20
* Jan Algermissen
|
| Come on Lars, I certainly don't mean to do NLP here.

No, but I have to suggest that to you to make you admit that the thing
is very far away from being machine-processable. In fact, even then I
can't get a straight admission.
=20
* Lars Marius Garshol
|
| and implement it correctly. The same applies throughout. N0393 and
| N0406 are both very far away from being implementable, and automated
| implementation of N0406 you can forget about so long as it remains in
| anything like its present form.
=20
* Jan Algermissen
|
| Yeah sure, use your imagination a bit ;-)

Rather than use my imagination I would very much prefer it if people
could stop pretending that the thing is something which it very
clearly is not, thank you very much.
=20
* Lars Marius Garshol
|
| It has been considered many times by the authors of N0396 over the
| past two years, and we have discussed it on this mailing list several
| times, but we have always decided against it for many different
| reasons. The costs of supporting reification for roles in name and
| occurrence assignments=20
=20
* Jan Algermissen
|
| Why is that more costly? Doesn't that depend on how the topic map
| will be queried?

It depends on what we require implementations to represent, and,
certainly, what we require them to support querying. If we did it as
you suggest it would be very awkward not to require support for
reification of name and occurrence roles, and in our view that
awkwardness (plus the other things I mentioned) is too much of a price
to pay.
=20
* Lars Marius Garshol
|
| and obscuring the conceptual structure of the model
=20
* Jan Algermissen
|
| "Obscuring the conceptual structure" ??
|=20
| What structure? Doesn't N0396 define the struture? How can the
| document that defines the structure at the same time obscure it?

Look at N0393 and you'll find an example of a document doing just
that. I assure you it is possible. In fact, I find it difficult to
take your surprise, real or pretended, seriously.

[1] For the record: Geir Ove Gr=F8nmo, Kal Ahmed, Arnar Lundesgaard,
    Espen Holje, and Robert Barta. That's five independent
    implementors working on independent implementations of the SAM.

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