[sc34wg3] Re: TMDM minor suggestion

Tue, 13 Dec 2005 20:28:20 +0100

(Sorry for breaking the threading here. The explanation is long and  
tedious, and involves dead laptops, etc.)

* Robert Barta
|
| I promise, I will never look at the doc again :-))

:-)

| - Page V:
|
|   Not sure whether part 6 (and 7) are already on the table?

They are not formally approved yet, so no.

| - 4.1
|
|   "The names of these properties..."
|
|   to what does 'these' refer to?

That word is just confusing. Now removed.

| - 4.1
|
|   "...as associated type..." wording is using terms (assocation,
|   type) in a different meaning than later. Might be a bit
|   misleading.

True. That word is redundant, anyway.

| - 4.1
|
|   'null' is not defined yet.

True. However, avoiding this sort of thing completely is just not
possible. Not even going to try here. :)

| - 4.1 3rd para
|
|   suggest: .... are - strictly speaking - redun..

Emphasizes the "strictly speaking" too much, I think. Makes it sound
like you have to be a pedant to think they are redundant, whereas they
are quite obviously so, and the "strictly speaking" is only there to
make people who complained about this sounding funny (why would we
have it there if it's redundant?) happy.

| - 4.1 4th para
|
|   suggest: ...infoset formalism for the purpose of illus...

What's there is idiomatically correct English, and is easier on my
ear.
| - 4.3 Set:
|
|   suggest: ...contain no two elements...

The "two" isn't required, and it could be "three", or ...
| - 4.3 Null:
|
|   suggest: consistent writing of Null (capitalized, different font?)

If so we should do the same with "set" and "string".
| - 4.4 Datatypes
|
|   "...only ... are strings and Null".
|
|   I thought IRIs are now there and XML, as defined in the same
|   section. I assume something else was planned to say here, but I do
|   not quite get what.

It's a bit confusing, but the sentence is referring to the types
defined in the previous section. Trying to clarify this by adding a
reference to that clause, but it may be better to rewrite this
paragraph in such a way that the reference is not needed.

| - 5.1
|
|   "Topic map constructs .......any number of item identifiers."
|
|   suggest simplification/correction:
|
|   "Every information item has at least one item identifer (see
|   merging)".

It really is any number, since having none is allowed. However, this
is really there to explain to someone who asked why they can have more
than one, given that in the syntax you can only have one ID. That's
now changing, and in any case it was a poor reason to increase the
size of the document. I'm deleting the whole para.

It says there are two situations:

a) equal item identifiers for non-topics: error
b) equal item identifiers for topics: merge

I'm not sure what it is that's unclear about it?

| - 5.3.1 typos
|
|   "....are statements, where_as the assignment__s of ...are not ..."

Fixed. Thanks!

No, that bit is actually crucial. It really means what it says.
| - 5.3.2 Note 1
|
|   "der_ference"

Fixed. Thanks!

| - 5.3.2 Note 1
|
|   Suggest s/does not exist/is not accessible/

Accepted.

| - 5.3.2 Example
|
|   Suggest to add a trailing slash to the IRI

Why? (I don't mean to be difficult here, just wondering why you care.
The syntax equivalence rules in the RFC says it's the same.)

| - 5.3.2
|
|   "Note the uncertainty...."
|
|   Suggest to make a NOTE.

We're still in the example. :)

| - 5.3.3 Scope
|
|   "..unconstrained scope.... is represented by the empty set"
|
|   So be it, but what it means is that implementations have to
|   be extremely careful when they handle scope: If they do set
|   intersection operations (for whatever reason) and if they end
|   up with an empty set then BEWARE(!) this all of a sudden would
|   be unconstrained-scopishly true!
|
|   Not overly natural, but I lack a better idea at the moment.

Actually, once you accept the "all subjects" interpretation of scope
this is the way it must be. See my theory of scope paper, where
operators are defined that build on that interpretation. It all works
out fine, and you see quite clearly that it *must* be the empty set.

We have three examples in order to show the use of scope on names,
occurrences, and associations. We could have replaced the two person
names with A and B, the instance with X, and the types with T1 and T2,
but IMHO that's a poorer example. And, really, someone who can't
understand the example with the two person names, the script name, and
two types, but can understand it with meaningless identifiers is a
pretty strange person.

Both editors think this one is OK the way it is. And, besides, it lets
one editor show off his erudition. That sounds like more than enough
reason to keep it to me. :)

| - 5.3.4 Reification Note 1
|
|   Suggest to add a reference to it. Sowa?

It's defined in TMDM, so you don't need to know what the term means in
general.

| - 5.3.4
|
|   " ... to topic map constructs such as ...."
|
|   Suggest to delete things after 'such as'.

Accepted.

| - 5.3.4
|
|   "is present in a structured form"
|
|   Suggest: explicit form
|
|   Suggest to drop everything after "that can be ....."

Accepted.

| - 5.3.5 Topic properties
|
|   ad equality rule: I would think that people may wonder how it might
|   go about that two topics at some point share a common item  
identifier.
|   This is probably only during merging, yes?
|
|   I suspect that we should say something before that a TMDM instance
|   is not necessarily 'completely merged' and that section X describes
|   this process in detail.
|
|   It is just that I had to sit back and wonder.

This is where TMDM really is quite procedural. Normal programmers
never detect anything funny here, but those with a bit of mathematical
background find it odd. We probably should have done something about
this earlier, but I think it's a bit late now. We could do what you
suggest, but I doubt it would really help.

It is the only place where it was necessary, and this was an ugly
contortion necessary because of the workings of XTM 1.0. Now that XTM
1.1 is being redesigned it may be that we can get away from this.
We'll give this one some thought.

| - 5.3.5 Note 1
|
|   Suggest "...should not be used" -> "must not be ...."
|
|   Suggest to make the whole note only one paragraph.

Hmmmm. We can't have "must", it must be "shall" (ISO rules), and if we
have "shall" it's no longer a note. However, this is strictly speaking
normative text. We'll move it to 5.3.2 (where it really belongs
anyway) and take it out of the <note> wrapping.

| - 5.4 topic names Note 1
|
|   If a name is a special occurrence and an occurrence is a special
|   association, should we not make this more explicit in some Annex?

It's too late to add that kind of thing now. In any case, I think this
is the sort of thing that part 5 should do.

| - 5.4 topic names [ reifier ]
|
|   Suggest "if present" -> "if not NULL"

Accepted.

| - 5.6 Occurrence
|
|   I have a question: if I create an occurrence of
|   type 'homepage' for a topic 'robert'
|
|   robert
|   oc (homepage): http://nowhere.com/
|
|   Is then 'homepage' automatically, implicitely a subtype
|   of 'psi.topicmaps.org/occurrence' ?

As we had it: yes. Following the Atlanta meeting, all this has now
been removed, however. We didn't feel confident that we really had all
the semantics right here, and there isn't time left to *get* it right,
unfortunately. So this is now all gone.

We could. Leaving it.

|   "Any change..."
|
|   If TMDM instances are allowed to be 'redundant', then why
|   is the 'change' necessary to trigger merging?

It's what triggers violation of the merging rules. Redundance, per se,
is not the issue; the issue is whether you violate the merging
rules. If you do, you are redundant for certain, if you don't, you
might still be.

|   Suggest: "..a set" -> "any set"

Accepted.

| 6.2 ad 1)
|
| Is it necessary to say "Create a new topic item with item identifier
| C"?

We've tried just reusing A, but that didn't come out so well. It seems
better this way.

| 6.2 ad 8)
|
|   I note that the original topics are not removed?

They are, but so subtly that people tend to miss it. See 2) and 3). :)
| 6.3 ad 6)
|
|   Suggest:
|
|   "..non-null values, the _respective_ topic items shall..."
|
|   Suggest:
|
|   "..from the merged set _is then_ the value...."

It's not that easy, I'm afraid. "Set" is here a verb rather than a
noun. Added a "be" in front of it to make this clearer.

| 7.2
|
|   Suggest: "topic type is know _to be_ an instance .."

No, this is linguistic. We could equally well have said "is called 'an
instance' of that topic type". So it's not "known" in a logical sense.

| 7.2
|
|   Is the note that type-instance is not transitive any relevant
|   to TMDM? (Same question for subtype-supertype transitivity).

It's relevant in the sense that this is something people often trip
over, so it seemed useful to go the extra mile here.

| 7.3
|
|   Suggest: "....relationship implies ..."

Accepted.

| 7.5
|
|   Most of the Usage sections are empty. Looks a bit odd.

Yes. This has now been moved into an annex A, and is now only for
glossary terms as glossary terms (or classification keywords). The
model significance of these has been removed completely.

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