[sc34wg3] Comments on latest TMRM draft

Fri, 15 Jul 2005 12:52:11 +0200

* 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?

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

I'll grant you that it's important, but I'm confused about what it's
doing in TMRM. To me it seems to belong to TMQL. TMRM never had this
kind of thing before, and there seems no good reason why it should
have it now.

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

It's a path language couched in mathematical terms. But that's not the
issue. The issue is: what is it doing in TMRM? Why is it there?

| 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.

Well, what utility do you think it has, and why do you think it
belongs in TMRM?

* 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 would assume the "key/value" pair that together compose the
| "property."

That's certainly what you wrote in TMRM.

| If we used "key" to mean property or "property" to mean property
| value assignment, it is news to me. 

No, I'm not saying you did that; I'm saying that's what I think most
readers would expect you to do.

* 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?

| [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.

* 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?

| 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.

* 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.

| 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.

| 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.

* Lars Marius Garshol
|
| 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.

* Patrick Durusau
|
| I don't thnik 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.

Possibly; and that brings us back to the question of what the path
language is doing in TMRM.

* 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.

* 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.

* Lars Marius Garshol
|
| 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?

* Patrick Durusau
|
| Err, it is defined on the map. At least that is what I wrote. How
| did you see it otherwise?

I screwed up. Nevermind. :-)

* Lars Marius Garshol
|
| --- 3, 4, and 5
| 
| The purpose of these clauses is not clear. Some clarification would
| be welcome.

* Patrick Durusau
|
| See initial comments.

Well, they don't make the purpose of these clauses any clearer.

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