Path language in TMRM: was Re: [sc34wg3] Comments on latest TMRM draft

[Patrick Durusau]

Lars,

I will reply separately to your other points but since the reason for 
the path language is a major point of your post I wanted to have a 
separate thread on that point.

True, a path language was has not been present in prior versions of the 
TMRM.

Recall that in Amsterdam a majority of the national body comments on the 
TMRM CD vote indicated that the formalism of Barta's Tau and Tau+ models 
should be incorporated into the TMRM. The Tau and Tau+ (now T+) papers 
contained the path language formalism.

I understood the directive of the committee was for the editors to 
incoporate the formalism of the Tau and Tau+ models into the TMRM. I 
used the latest version of that work, dated July 11, 2005.

Beyond simply following the committee's directive, I think there are 
good reasons to have the path formalism in the TMRM.

What is a disclosure?

The TMRM describes it as "constraints" on a map.

Now if I am going to constrain some part of a map, I surely have to have 
some mechanism to express where a particular constraint is going to be 
applied.

That is to say that I have to express the constraint itself, whatever 
that may be, and the place(s) on the map where the constraint is in effect.

To say a construct's name and some "property" name within it, is just as 
surely a path language as /text/div/p/q.

Note that the TMRM is not defining a specific path language but a formal 
representation of any path language, the specifics of which would be 
found in a Subject Map Disclosure.

All of that is to say that in order to require any meaningful 
disclosure, that is disclosure that says what the constraints are and 
where they are applied, a formal representation of a path language, one 
that does not bind anyone to a particular instantiation of a path 
language, is quite useful.

I will ask Robert to post a link to his paper with Heuer and Salzer, 
dated July 11, 2005, which is the latest version of the T+ model. In 
section 5 of that paper, which corresponds to section 5. Ontological 
Commitments of the TMRM draft for Montreal, it becomes clear that the 
path expressions underlie the disclosure mechanism.

If it is of any comfort, I too started from the premise that a path 
language, even a formal one, should be considered as out of bounds for 
the TMRM. After a number of exchanges with Barta and a rather close 
reading of his more recent work, I have come to conclude that a formal 
path language is part of any meaningful requirement for disclosure of 
ontological commitments and should be part of the TMRM.

Note that the definition of a constraint as a set of path expressions 
allows the definition of a "satisfaction relation" between the 
constraints and the map in question. Along with the types, that becomes 
the disclosure of ontological commitment.

While you may not find that entirely persuasive, does it get us any 
closer as to why I think there should be a path language in the TMRM?

Hope you are having a great day!

Patrick

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

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