[sc34wg3] Comments on latest TMRM draft

[Patrick Durusau]

Lars,

I have clipped out your questions on the path language that I replied to 
in the separate thread.

As far as the other issues:

Lars Marius Garshol wrote:

>* Patrick Durusau
>| 
>| 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.
>
>I guess the difference between us may be that you attach value to the
>text that is not definitions and formalism, whereas I think the only
>value in the document lies in the definitions/formalism. In my eyes,
>the rest is just prose to make the definitions/formalism easier to
>read.
>
>| As you say, someone who does not read it carefully isn't going to
>| get much out of it anyway.
>
>That's true, but as far as I can tell this would only make it harder
>to read, and there would be no detectable gain. What would the prose
>be doing if not presenting these definitions?
> 
>  
>
Just briefly as we could spend a lot of time on this admittedly non-TMRM 
topic.

Rather than simply "mak[ing] the defnitions/formalism easier to read" I 
see the prose as a context of usage that makes the definitions 
meaningful. Admittedly a definition should make a term "meaningful" but 
that succeeds only to a degree.

 From my perspective, if the definition has done as well as could be 
expected, then I don't have to repeat (should never repeat anything in 
an ISO standard is advice I have heard given) that and can assume the 
reader has the basic gist of what needs to be understood and I can then 
build upon that understanding.

It may be from my biblical/ancient near eastern language background as 
most explanations of those grammars start with a fairly large array of 
definitions and then toss you into contextual use of what has been 
defined. Admittedly it is only one style among endless choices and may 
not be the best one. It is, however, one that I know fairly well.

Your contextual definition style, which I note continues in the current 
draft of the TMDM, simply grates on my ears. ;-) Other readers, 
hopefully a majority beyond the committee, may find it completely 
intuitive.

I am interested in suggestions of other approaches or ways I could 
improve this one. It just happens to be one that works for me. I am 
interested in knowing if it does not work for others or if there are 
alternatives that might work better for a larger number of members of 
the committee or the larger audience beyond the committee.

<snip>

>* Lars Marius Garshol
>|
>| 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.
>
>* Patrick Durusau
>|
>| 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?
>
>Typically, things like "length" or "dc:title" or "[subject
>identifiers]" are generally considered properties, while things like
>"(length, 185)", "(..., dc:title, 'TMRM')", and so on are considered
>property instances (old TMRM terminology, if I remember correctly) or
>property value assignments (groves?).
>
>I guess I could make a table like this:
>
>  +-----------+-------------------+
>  | TMRM term | LMG expectation   |
>  +-----------+-------------------+
>  | property  | property instance |
>  +-----------+-------------------+
>  | key       | property          |
>  +-----------+-------------------+
>  | value     | value             |
>  +-----------+-------------------+
>
>  
>
I don't know that it would be any more representative that what you and 
I have said as individuals but perhaps other members of the committee 
would like to voice their preferences?

I really see it as a preference issue and not something fundamental. Or 
if preference seems too casual, perhaps as a communication issue? I 
really have no interest in polling a large community or trying to 
assemble ammunition for one set of terms versus another. I would prefer 
that we (the committee) reach the best consensus we can on what is 
likely to work and just go with that. It is not always possible to guess 
what will work best and so we will need to make a choice and see how it 
flys.

<snip>

>* Lars Marius Garshol
>|
>| What is the difference between proxy delimiters and set delimiters
>| when proxies are sets?
>
>* Patrick Durusau
>|
>| Probably unnecessary but I have an editorial problem when a paper
>| uses set notation (for sets) and then uses it as syntax in examples.
>
>But the examples are examples of sets, so what other notation could
>possibly have been used?
>
>  
>
Err, sorry, I was not reading the examples as using sets but simply as a 
notation of proxies since each example (as I read them) as single proxies.

>| [1.3]
>|
>| 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.
>
>Who cares about the prose? It's the definitions that matter. If you
>put the definitions alphabetically at the front and then just had
>plain prose you would pretty much guarantee that nobody would ever be
>able to decipher the document.
> 
>  
>
Sorry, we simply disagree here. Not the style to which I am accustomed, 
either in standards or elsewhere.

>* Lars Marius Garshol
>|
>| To say that "values are unconstrained" seems like hand-waving. At the
>| very least some minimal conditions have to be spelled out.
>
>* Patrick Durusau
>|
>| Well, they have to be disclosed? What more should I say? (serious
>| question) 
>
>Can they be compared? Do they have types?
>
>  
>
Yes.

>| I really don't think putting limits on values should happen anywhere
>| but in Subject Map Disclosures. 
>
>That's OK, but minimal requirements for values (and the definitions of
>what those values are) can be laid down.
>
>  
>
Yes, and we agree on compare and have types if that what you mean by 
minimum requirements.

>* Lars Marius Garshol
>|
>| 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.
>
>* Patrick Durusau
>|
>| ?? Well, if you consider that subject proxies are themselves tuples
>| (identifier,proxy) I fail to see your point.
>
>The definition of proxy says it's a set of (key, value) pairs, and so
>there is no identifier in the proxy.
> 
>  
>
And the prose, sorry!, says all proxies have identifiers, unique ones at 
that.

>| 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. 
>
>You're using set theory, and set theory says sets can be compared for
>equality, and there's no escaping from that. It follows from this that
>values must necessarily be comparable.
>
>  
>
Yes, see my post on this being an issue, along with identifiers we need 
to resolve.

>| 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.
>
>No. Certain rules are given by the use of set theory. If you don't
>want those rules you have to use something else.
> 
>  
>
Yes, to be resolved.

<snip>

>* Lars Marius Garshol
>|
>| 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.
>
>The first sentence is wrong: for "property" read "proxy".
>
>* Patrick Durusau
>|
>| 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. ;-)
>
>Well, I understand perfectly well how the TMRM draft uses the term
>"property". It doesn't match my understanding of the term, but I have
>no problems with understanding the TMRM usage of it. What that comment
>is saying is that:
>
> (1) I don't think it makes sense to only allow a key to appear once
>     in a particular proxy.
>
> (2) I think if such a constraint is to be introduced it needs to
>     appear in the definition of a proxy, not in the definition of the
>     keys(x) function.
>
> (3) I think if the constraint is to be introduced it needs to be
>     defined formally, not in prose.
> 
>  
>
OK to 2 and 3, I think we need to discuss in Montreal #1.

>* Lars Marius Garshol
>|
>| Why does values(x) produce a bag? And shouldn't the definition use
>| some other formalism to indicate that it produces a bag?
>
>* Patrick Durusau
>|
>| Yes to formalism.
>
>What I'm saying is that 
>
> (1) I don't think values(x) *should* produce a bag.
>
> (2) Unless my maths is all messed up the values(x) function actually
>     does produce a set, and the definition needs to be changed if it
>     is to produce a bag as the prose says it does.
> 
>  
>
Hmmm, looks like an error in changing from T+'s saying that there could 
be more than one instance of a key. I think the reasoning for a bag was 
that if there was more than one occurrence of a key in a proxy that the 
multiple occurrences of the value for the mulitple occurrences of the 
key should not be treated as a set. Under the same reasoning, the keys 
were treated as a bag.

Let me know if I skipped anything. I took a snack break in the middle of 
composing the response but I think I covered everything.

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!