[sc34wg3] Comments on latest TMRM draft

[Patrick Durusau]

Lars,

Lars Marius Garshol wrote:

>Rather than respond to other people's comments all the time I figured
>I would try writing some comments of my own for once. :-)
>
>  
>
:-)

A couple of general comments and then some (but not all) comments on 
specific points.

Overall order of presentation? Problematic to be sure.

I think we may disagree on how to fix that however. I would prefer to 
put all the stock definitions, "We define *** as ***" sort of stuff in a 
list at the front since that keeps us from having to interrupt the flow 
of the text with stock definitions. As you say, someone who does not 
read it carefully isn't going to get much out of it anyway.

On the path language material, I think that may be more important than 
it first appears.

First, note that it is not defining a path language to be implemented 
but simply a declaration of the requirements of a path language.

Second, since it does not define a path language, it does not constrain 
any  whatever choices might be made in specifying a path language.

Third, I know Robert sees it as providing a foundation for TMQL, without 
limiting it to any particular implementation.

I am not suggesting those are definitive answers but I think some of the 
off-putting formalism can be expressed in such a way that the utility of 
the path language materials will become more apparent.

>--- 1
>
>Term "property": this terminology is confusing. Usually properties and
>property instances or property value assignments are considered
>different things. Here, "key" means property, while "property" means
>property value assignment. This seems backwards compared to the normal
>usage of these terms.
>
>  
>
Sorry, you are missing me with that one. If I say, "Give me the property 
(assuming there is only one) on element X" what would you think I am 
going to get back?

I would assume the "key/value" pair that together compose the "property."

If we used "key" to mean property or "property" to mean property value 
assignment, it is news to me. NOTE: Not denying you may find that sort 
of error in the draft. I think you hit on below one place where we 
tripped over our own definition of property. ;-)

>--- 1.2
>
>It might be better to do without this section, as anyone who does not
>already know these symbols is unlikely to get very far in reading this
>document.
>
>"set union" is conventionally represented by U (LaTeX \cup). That
>symbol is indeed defined below as simply "union", despite also being
>"set union". Suggest using only \cup for "set union".
>
>|| is used to mean "or", but generally LaTeX \lor is used for this.
>Suggest using \lor instead.
>
>Single right arrow is used for implication, but the conventional
>symbol is double right arrow. (Like the symbol for logical
>equivalence, but without the left arrowhead.) What is the difference
>between "logical implication" and "implication"?
>
>"subset equals" is usually defined as "true subset of *or* equal to".
>
>The "product" symbol looks wrong. Usually \prod is used for this, and
>the symbol given usually means coproduct.
>
>  
>
I will check on all these.

>What is the difference between proxy delimiters and set delimiters
>when proxies are sets?
>
>  
>
Probably unnecessary but I have an editorial problem when a paper uses 
set notation (for sets) and then uses it as syntax in examples.

>--- 1.3
>
>These definitions are meaningless out of context.
>
>  
>
Not so! ;-) Seriously, I think having even fuller definitions at the 
front would make the prose flow better (not saying well). We are not 
writing a logic paper but a standard and we are free to organize it as 
the committee thinks makes the best presentation.

>--- 2
>
>The order of presentation does not seem optimal. It seems best to
>start at the bottom and build up instead of starting in the middle.
>The order of presentation used defines proxies in terms of properties,
>which are not defined yet, then goes on to define properties without
>having defined keys and values, and so on...
>
>  
>
See initial comments.

>To say that "values are unconstrained" seems like hand-waving. At the
>very least some minimal conditions have to be spelled out.
>
>  
>
Well, they have to be disclosed? What more should I say? (serious 
question) I really don't think putting limits on values should happen 
anywhere but in Subject Map Disclosures. I have no idea what values 
people are going to want now much less five years from now. Or ten years 
from now. Why build in limits that are not meaningful at the level of 
abstraction the TMRM seeks to reach anyway?

>Another obvious constraint on id and id-1 seems to have been left out,
>which is that for all x in X id-1(id(x)) = x. This may be implied by
>the function names, but it seems better to spell it out.
>
>  
>
Yeah, I think I simply left that out. Although, there are things I think 
we should presume from general set theory and not feel compelled to 
include explicitly. This is not one of those.

>On the identity of proxies: the difficulty here is that in mathematics
>there is no way to distinguish between two proxies whose values are
>equal. However, the TMDM representation done in the TMRA '05 paper by
>Barta and Heuer seems to get into difficulties because of this rule.
>Further, it does seem that an uneasy relationship between identifiers
>and proxies exists in the current draft.
>
>  
>
?? Well, if you consider that subject proxies are themselves tuples 
(identifier,proxy) I fail to see your point.

The other point and I know that at least Robert disagrees with me on 
this, is I don't see why we can't say that subject proxies are 
considered equivalent only when equivalence is defined. That seems 
simply enough to say. If in a particular Subject Map Disclosure, you 
want the all values are equal means equivalence, I can't stop you. On 
the other hand, if I want some other rule, I am free to choose it.

The key (sorry) to me is that the TMRM enable disclosure of those choices.

>The proxies defined using the set of natural numbers seems very
>misplaced. Firstly, it redefines semantics defined in TMDM. Secondly,
>it does not seem to serve any obvious purpose. Thirdly, the
>definitions seem grotesquely distorted. Suggest that this be cut
>altogether.
>
>  
>
I don't thinik the T+ paper intended to redefine the semantics found in 
TMDM. My reading of it was that it was necessary to support the 
abstractions of the path language, nothing more. Cf., my comments on 
proxies without meaningful properties.

>Why cannot keys occur more than once in a property, and why is this
>constraint first introduced in the definition of the function keys(x)?
>This constraint seems likely to cause difficulties further down the
>road. Even if keys *did* occur more than once, the result would still
>be a set.
>
>  
>
I think we may have tripped on our own definition of property here, 
perhaps not. I think we need to save this one for Montreal because I 
don't think we are operating wth a common notion of property. Not that 
face to face we are any more likely to agree but at least we may 
understand why we are disagreeing. ;-)

>Why does values(x) produce a bag? And shouldn't the definition use
>some other formalism to indicate that it produces a bag?
>
>  
>
Yes to formalism.

>The proxy merge view function should surely be defined on a map rather
>than a proxy, given that proxies will occur as values in other
>proxies? What is the interaction with the id() function?
>
>  
>
Err, it is defined on the map. At least that is what I wrote. How did 
you see it otherwise?

Not sure about the id() function question but I am real tired so will 
try it again tomorrow.

>--- 3, 4, and 5
>
>The purpose of these clauses is not clear. Some clarification would be
>welcome.
>
>  
>
See initial comments.

Yes, it is very rough but I think we have all the various parts of the 
formalism in place and Robert is going to be in Montreal so I am hopeful 
we can make very serious progress on the draft.

Yes, we do and probably will disagree in places but I think the 
formalism will help clarify where those places are, if not help us see 
ways past the disagreements.

Hope you are having a great day!

Patrick



-- 
Patrick Durusau
Patrick@Durusau.net
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model
Member, Text Encoding Initiative Board of Directors, 2003-2005

Topic Maps: Human, not artificial, intelligence at work!