[sc34wg3] More thoughts on Section 3 of TMQL

[Patrick Durusau]

Greetings!

A few additional comments about Section 3 of the current TMQL draft 
(http://www.isotopicmaps.org/tmql/tmql.html).

3.1 Syntax Conventions, numbered paragraph 1.

The abbreviations "\w" for the character class "[a-zA-Z0-9_] 
(alphanumeric characters and the underscore character)" and \d for 
"digit characters [0-9]" are likely to be confusing to people with an 
XML schema background.

There, \w stands for:

[#x0000-#x10FFFF]-[\p{P}\p{Z}\p{C}] (Any Unicode character, except a 
punctuation, separator, or other character)

and \d stands for: [\p{Nd}] (Any decimal digit (not limited to ASCII)

(I can hear Robert saying: "But every paper defines its own 
abbreviations...." ;-) )

True, but we want this "paper" to be read and understood by others, some 
of who aren't willing to expend large amount of time learning our 
particular take on abbreviations.

Besides, we use "\w" only nine times in the entire document and  "d"  
only seven times in the entire document so dropping the use of those 
abbreviations isn't going to cause substantial hardship.

What appears to be the third paragraph under this subsection begins 
with: "As usual,..." I am not going to comment on matters of style at 
this point, mostly because it would make my posts too long to be useful. 
Suffice it to say that the draft does need a editorial pass for style of 
expression after it is substantively correct.

3.2 Informal and Formal Semantics

Well, this is a matter of style to a degree but do note that ISO 
standards are *not* divided into ambiguous and non-ambiguous parts to be 
indicated by typography. It may be difficult but we really should be 
able to say what we mean in English as well as in less expressive 
languages.

BTW, to at least partially answer the general complaint about TMQL being 
too complicated, can we have a show of hands for who grokked XSLT 2 from 
the standard and did not supplement their reading with stuff from either 
Micheal Kay or Jenni Tennison?

I suspect in any group of XSLT developers, save for those on the 
committee and I wouldn't bet on all of them, almost everyone else uses 
secondary materials and then confirms their understanding with the 
standard.

There is no shame in learning complex material in such a manner.

I would lose this subsection in its entirety.

3.3 Ontological Commitments

Err, "transitivity-free" occurs only twice and both times in this 
subsection.

Ah, but if I make it to 6.3.2 Pragmas, 1. taxometry, I learn that: "To 
turn off transitivity, the QIRI must be set to tm:intrasitive."

Hmmm, how about a list?

*****

tm:transistive - subtype/supertype and type/instance relationships are 
as transitive.

Under tm:transitive, each subtype or supertype will be interpreted as a 
subtype and supertype of itself (reflexion).

tm:intransitive - subtype/supertype and type/instance relationships are 
not transitive.

*****

BTW, under 6.3.2 Pragmas, 1. taxometry, we say: "...any subclass 
relationship in the effective map is interpreted transitively..."

But is that really true? Or is it only true for subtype/supertype and 
type/instance as defined by the TMDM?

And what if I want different treatment for subtype/supertype versus 
type/instance, even as defined by the TMDM?

Is this an all or nothing proposition?

Not to say anything about other relationships that I may wish to 
declare. How are they to be treated? Or is that covered under the 
"...leaves it to the environment to perform any inferencing."?

Oh, in the prefixes = namespace final listing.

Should *declare* namespaces for the standard and just say: "Namespace of 
TMDM concepts.", etc.

BTW, we don't define xsd nor dc.

And on "dc," note this is the only occurrence of this prefix. Makes me 
wonder why we have it.

We don't use "xsd" outside of an example.

I would lose both xsd and dc and simply define the others as a list.

(For a much later discussion: I don't know that I agree with the 
"manifestation" of xsd and dc as topics and part of the environment map 
under 6.3.1, but I have to admit that it is an intriguing idea.) If this 
gets mentioned here, it should be a note or reference to where that 
happens.

******************

Summary:

OK, well, at the expense of being a little more verbose, there are 16 
places where we can avoid potential confusion in regex expressions, 
there is a section (3.2) that we can lose in its entirety, some 
suggestions are made and questions asked about 
transitivity/intrasitivity and finally there are some questions about 
the declaration of namespaces.

No, I am not going to claim that any of these changes will suddenly make 
TMQL suddenly transparent and obvious.

What is ironic is that the process of understanding TMQL is the same 
process that two different speakers who are describing the same subject 
but using different vocabularies must do. I am sure everyone following 
this discussion has ways they would describe the same subjects that are 
discussed in TMQL, but differently from the way those subjects are 
described in TMQL.

Creating your personal map between those two isn't going to be easy but 
I think it will be very rewarding in the long run.

Hope everyone is having a great weekend!

Patrick

-- 
Patrick Durusau
patrick at durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)