Steve Newcomb wrote:
> Waclaw Kusnierczyk <Waclaw.Marcin.Kusnierczyk@xxxxxxxxxxx> writes:
>
>> 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.
>
> You're correct, of course, but I can't resist this opportunity to
> explain why, using the terms of the Topic Maps Reference Model.
>
> A subject proxy is always a non-empty set of property instances. (A
> subject proxy is never a name, but read on.)
>
> 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.)
>
> 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.
>
> 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.
>
> 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. (01)
I see two ways out of this trouble:
- either you choose some primitives (or: choose something as a
primitive) and then define all other elements relative to the primitives;
- conversely, define each element in terms of other elements, the
interpretation then being dependent on the structure as a whole, based
on its isomorphism with the structure of what the interpreter perceives. (02)
While in the first case you must make assumptions as to the nature of
the intended recipient in order to assure, by carefully choosing the
primitives, that the message will be interpreted correctly, in the other
case you must provide a description (a set of constraints) as close in
complexity to that what is being described, which in the limit would
mean sending the subject as the message. (03)
> 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.)
>
>>>> 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.
>
> 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. (04)
Agreed. (05)
>
>>> 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.
>
> 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? (06)
Depends on what you mean by 'message' (and 'intention'). (07)
>
> (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?) (08)
It depends who the intended recipient really is. A DoS attack is not
really intended as a series of messages to be read by you -- a human,
but a series of messages intended to make the server break -- precisely,
by sending it valid, meaningful (at least on the one-to-one basis)
messages. (At least, as the term is commonly used in the computer
networking jargon.) (09)
There is perhaps a theory of message worth of referring to here, but,
intuitively, I think that any data can be considered a message if one
observes any change that can be attributed to a (putative) reception of
the data, and, perhaps, if one can attribute the (putative) sending of
the data by some (putative) sender. (010)
If you receive lots of spam which does not communicate anything to you
and you simply ignore it, perhaps the hidden message is 'ignore me'? (011)
>> 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.)
>
> Very true.
>
>> 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.
>
> 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. (012)
Seems to me I have to have a look at the specs. (013)
vQ (014)
>
>
> -- Steve
>
> Steven R. Newcomb, Consultant
> Coolheads Consulting
>
> Co-editor, Topic Maps International Standard (ISO/IEC 13250)
> Co-editor, draft Topic Maps -- Reference Model (ISO/IEC 13250-5)
>
> srn@xxxxxxxxxxxxx
> http://www.coolheads.com
>
> direct: +1 540 951 9773
> main: +1 540 951 9774
> fax: +1 540 951 9775
>
> 208 Highview Drive
> Blacksburg, Virginia 24060 USA
>
>
> (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.)
>
>
> _________________________________________________________________
> 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
> (015)
--
Wacek Kusnierczyk (016)
------------------------------------------------------
Department of Information and Computer Science (IDI)
Norwegian University of Science and Technology (NTNU)
Sem Saelandsv. 7-9
7027 Trondheim
Norway (017)
tel. 0047 73591875
fax 0047 73594466
------------------------------------------------------ (018)
_________________________________________________________________
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 (019)
|