Waclaw Kusnierczyk <Waclaw.Marcin.Kusnierczyk@xxxxxxxxxxx> writes: (01)
> Steve Newcomb wrote:
> > Waclaw Kusnierczyk <Waclaw.Marcin.Kusnierczyk@xxxxxxxxxxx> writes:
> >
> >
> >> It appears to me that in most circumstances you will not be able to
> >> provide the context, but rather a proxy, another expression describing
> >> the context. Now we get the pains of infinite regress: to know what
> >> the context is, the expression intended to be a proxy of the context has
> >> to be provided with a context (another proxy, I guess), and so on. With
> >> a finite and ungrounded representational artifact, it means that it
> >> would be impossible to interpret any expression.
> >
> > Very true.
>
> And the proxy for a context may be not an expression *describing* the
> context, but just a *name*, in which case it itself requires
> interpretation even more than if it were a description. (02)
You're correct, of course, but I can't resist this opportunity to
explain why, using the terms of the Topic Maps Reference Model. (03)
A subject proxy is always a non-empty set of property instances. (A
subject proxy is never a name, but read on.) (04)
Each property instance does two things: (1) it invokes the class of
which it's an instance, and (2) it exhibits a value (data of some
kind). The property's class is always itself the subject of at least
one proxy in the same "subject map". (And that's why the Reference
Model assumes that every property instance's class invocation is, for
all practical purposes, some sort of reference to a subject proxy.) (05)
In every subject proxy, at least one property instance must identify
the proxy's one-and-only subject. In practical terms -- at the
operational level -- this means merely that there must be a
commitment, disclosed in terms of property classes, as to how to
detect when any two proxies should be merged because they both
represent the same subject. (06)
So the "name" you're talking about cannot be a subject proxy (a name
is not normally a set of property instances), but a name *can* be the
value of a property instance in such a proxy. And if the name is
intended to identify the subject of the proxy (and that *must* be the
intention if it's the only property in the proxy), then there must be
some disclosed circumstances under which that proxy would have to be
merged with some other proxy. For example, the applicable explicitly
disclosed rule might be that when the same name is the value of a
property of another proxy, and that other proxy's property is an
instance of the same property class, then the two proxies must be
merged. (07)
Your basic point is still correct, because at some level the whole
thing must boil down to something, and it may well boil down to
nothing more than a name in a context. (08)
I would point out, however, that in the Topic Maps Reference Model,
the name's context cannot be left unspecified, and that subject
proxies are never completely immune to merger with other subject
proxies. Among other things, this means that subject proxies are
ephemeral; only their subjects persist. (Or, more precisely, only the
addresses of their subjects, in each of one or more specific universes
of discourse [contexts], persist.) (09)
> >
> >> The only way out that I can see is to assume, at some iteration, that
> >> the interpreter will itself/himself/herself interpret the expression (be
> >> it the primary expression or any of its context-...-contexts) in the
> >> correct way, that is, that the interpreter is able to (or is forced to,
> >> by its nature) apply the correct context.
> >
> > Yes, of course.
> >
> >> But if such assumption has to be made, then I see no reason, in
> >> principle, for why it would be reasonable to assume that the interpreter
> >> can apply the correct context for interpreting an expression's context
> >> expression, but it/he/she cannot apply the correct context for
> >> interpreting the primary expression without it being enclosed in a
> >> context-expression.
> >
> >> Could you justify your point? (Or explain where I am wrong, if I am.)
> >
> > I'm not sure what you're asking me to do, here. I'm going to guess
> > that you're asking about the bootstrapping/grounding problem: that the
> > process whereby interpretive guidance is known must actually land
> > somewhere.
>
> Yes, I think this is very close. That is, if you claim that to assure
> that an expression will be interpreted correctly one needs to add
> contextual information, one must be clear that it must either be assumed
> that that contextual information will be interpreted correctly without
> further (meta)context, or that (meta)context must be provided as well.
> The question is at which level n of context^n to stop to be sure about
> the interpretation; you seemed to make the claim that an expression
> (about the domain, I guess, an expression I call, in this context ;)
> 'primary') *must* be supplied with a context (expression), while you
> seem to implicitly assume that the context (expression) will be
> interpreted correctly without further effort. While it is clear to me
> that grounding must take place at some context level, what you seem to
> claim appears to me to be an ad hoc solution. (010)
I guess I'm saying that, at bottom, all solutions are ad hoc
solutions; no one solution is the Holy Grail. Benefits accrue to us
when we face up to the fact that endlessly diverse ad-hockeries are a
fact of life, and one that we'd better learn to deal with efficiently. (011)
> > I worried about this for a long time and I finally decided that I
> > needed to demonstrate that the problem can be solved. I wasn't smart
> > enough to figure it out any other way. And, at least for me, it
> > proved to be very tedious and taxing to make a system that could
> > bootstrap itself from within itself in the necessary self-exposing,
> > self-disclosing way. But it was, in fact, doable. (I could do it
> > better now, now that I know what to do, but the original code can be
> > found at versavant.sourceforge.net.)
> >
> > Basically, there needs to be a subject proxy for each universe of
> > discourse, and each universe of discourse basically consists of a set
> > of subject proxy property classes. There needs to be at least one
> > underlying "system universe of discourse" (in Versavant, this is
> > called the "system topic map application" or "system TMA" or "Vsys"),
> > which provides the property classes that are instantiated in the
> > proxies whose subjects are themselves property classes. The grounding
> > problem is thus finessed: the "bottom turtle" in the stack of
> > ontology-turtles is a self-grounding one. (If my "stack of turtles"
> > metaphor is opaque to you, see
> > http://en.wikipedia.org/wiki/Turtles_all_the_way_down)
> >
>
> The issue is really about which context should we assume that the
> receipient of the message must, or simply will, share with the sender. (012)
Yes. I would argue that no message is ever sent by one human being to
another in the absence of some expectation that there is sufficient
shared context to enable the message to be understood as intended by
the sender. The fact that this expectation is often betrayed, and
communication fails, does not change the fact that the expectation is
always there. Otherwise, why send the message? (013)
(As I think about it, I get a lot of spam these days that communicates
absolutely nothing to me. So maybe I'm wrong. Maybe people send me
messages with no expectation that I will understand them, as in the
case of certain forms of denial-of-service attacks. But those aren't
really messages, are they?) (014)
> You can wrap the term 'cell' with the context 'organism' to avoid
> confusion with, e.g,, cells in batteries, geometry, or prisons, but if
> you send the message to martians, you may need to wrap the term
> 'organism' in some context as well -- assuming that at some point we
> share the way we interpret messages (or what appears to be a message;
> we clearly also need to share the way we interpret something as a
> message or not.) (015)
Very true. (016)
> In XML the situation is clearly in your favor, in that an unqualified
> identifier cannot be treated as unambiguous and must be interpreted only
> in the context of either an explicit or implicit namespace, as a
> qualified name or relative to the document base or the default
> namespace. However, it all boils down to the assumption that namespaces
> themselves are unambiguous, and that a namespace does not need further
> (meta)namespace -- which may, in fact, be misleading, despite the clear
> specifications of intention of the authors of XML. (017)
Yup. That particular missing self-description is an example of the
kind of problem we're trying to address with the Topic Maps Reference
Model. It's really defining a rhetoric that requires specificity
about what's being talking about, and that demands the consequences
(the mergings of subject proxies) that such commitments naturally
entail. (018)
-- Steve (019)
Steven R. Newcomb, Consultant
Coolheads Consulting (020)
Co-editor, Topic Maps International Standard (ISO/IEC 13250)
Co-editor, draft Topic Maps -- Reference Model (ISO/IEC 13250-5) (021)
srn@xxxxxxxxxxxxx
http://www.coolheads.com (022)
direct: +1 540 951 9773
main: +1 540 951 9774
fax: +1 540 951 9775 (023)
208 Highview Drive
Blacksburg, Virginia 24060 USA (024)
(Confidential to all US government personnel to whom this private
letter is not addressed and who are reading it in the absence of a
specific search warrant: In keeping with the publicly-confessed
criminal conduct of the Bush administration, and with the
irresponsible actions of the pusillanimous and corrupt 109th Congress,
you are co-conspiring to subvert the Constitution that you are sworn
to defend. You can either refuse to commit this crime, or you can
expect to suffer criminal sanctions in the future, when the Executive
Branch of the government of the United States of America once again
demonstrates respect for the rule of law. I do not envy you for
having to make this difficult choice, but I urge you to make it
wisely.) (025)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (026)
|