[
Lists Home |
Date Index |
Thread Index
]
OK so I think we've hammered enough on this nail now. We pretty much agree
on this point.
The set of shared assumptions about a document may vary depending on the
context. There is no "generic processor" because there is no generic meaning
; your point about a "generic processor" does not mean that nothing can be
done with an unknown document.
Regarding your example, suppose the receiver is a browser. It assumes that
it has to render the document in some way. There can be an agreement between
the sender and the receiver, that has nothing to do with the 'meaning' of
the document, since the receiver does not have the code that can build some
meaning out of the document.
The agreement is just about another concept, the 'rendering' of the
document. If I (the browser) can ask the sender 'can you send me a renderer
for this document', and the sender and I agree about what a renderer is
(i.e. we have a common rendering framework with proper interfaces), then the
sender can send me the code that will enable me to render the document, even
if I don't have a clue of what all those 'p', 'G', 'H', etc. are all about.
Granted, security is an important issue in this case, because the downloader
renderer may decide that "<m t='Q'>" means "execute rm -Rf /*".
Note that the code download is not necessarely from the sender to the
receiver. We could imagine that the receiver sends some serialisation code
to the sender : the client can specify what should be sent and how. Duh,
looks to me like a client sending an SQL request to a server :P.
The simplest case of communication is when the sender and receiver have the
same level of assumptions, i.e. 'this is a description of a neural network
in FOOBAR format', with both sides having the code to read and write the
document.
But we should think about the possibility of having assumptions at a higher
level, e.g. both sides agreeing on the concept of 'neural network' or
'classification engine' (domain specific), 'rendering' or 'validation'
(generic). As those concepts are expressed both in code and data, it means
looking further than XML, which concentrates on data.
Regards,
Nicolas
>-----Message d'origine-----
>De : Eric Bohlman [mailto:ebohlman@earthlink.net]
>Envoye : jeudi 24 janvier 2002 10:36
>A : xml-dev@lists.xml.org
>Objet : Re: [xml-dev] There is a meaning, but it's not in the
>data alone
>
>
>1/23/02 11:45:25 AM, Gavin Thomas Nicol <gtn@rbii.com> wrote:
>
>>On Wednesday 23 January 2002 06:22 am, Pete Kirkham wrote:
>>> For any application, there is a hypothetical domain model, which is
>>> a representation of all knowledge of that domain. It is unlikely to
>>> exist in any complete realised form, but only in the heads of the
>>> experts in that domain.
>>
>>The "domain model" as you put it, is roughly equivalent to a
>>vocabulary with an associated set of semantics. So long as you agree
>>on the terms, you can communicate, and that is the whole point.
>>
>>The terms *intrinsically* do *not* have any meaning. Only in the
>>context of the interpreter dot hey have meaning, and only if the
>>knowledge is shared and agreed upon will useful communication occur.
>
>Bingo. *All* communication requires a set of shared
>assumptions on the part of both the sender(s)
>and the receiver(s). As others have pointed out, in the case
>of machine-to-machine communications,
>these assumptions are likely to be embedded in the sending
>code and the receiving code. It is not
>meaningful (hehe) to talk about "meaning" independent of those
>shared assumptions (in fact,
>according to the principle of the Intentional Fallacy, it's
>not even possible to talk about *the*
>meaning of a message, only a set of possible meanings with
>(unless you're absolutely hardcore PoMo)
>varying degrees of plausibility, for some definition of
>"plausibility"). It is therefore an
>oxymoron to speak of a message that completely encodes its own
>meaning independent of any entity
>outside the message itself. As the dictionary entry Len cited
>makes clear, the pre-image of a
>semantic mapping includes an environment, which cannot be
>contained in the message itself, unless
>the message somehow encodes all of reality in itself, which is
>not practical and IMHO not possible.
>
>We went all over this in my high school freshman English
>class, 30 years ago this fall (our teacher
>was quite a follower of S.I. Hayakawa). Exercises included
>attempts to assign a meaning to the
>words "glubdrub" and "grobjom"; the set of potential meanings
>included "stick this hairpin into
>that electrical socket."
>
>What does the following bit of XML *mean*?
>
><m t="Q">
> <s n="G">
> <t t="G" p="0.25"/>
> <t t="H" p="0.025"/>
> <t t="R" p="0.025"/>
> <t t="S" p="0.7"/>
> </s>
> <s n="H">
> <t t="G" p="0.25"/>
> <t t="H" p="0.05"/>
> <t t="R" p="0.025"/>
> <t t="S" p="0.675"/>
> </s>
> <s n="R">
> <t t="G" p="0.35"/>
> <t t="H" p="0.025"/>
> <t t="R" p="0.025"/>
> <t t="S" p="0.65"/>
> </s>
> <s n="S">
> <t t="G" p="0.1"/>
> <t t="H" p="0.005"/>
> <t t="R" p="0.005"/>
> <t t="S" p="0.89"/>
> </s>
></m>
>
>1) Do the single-letter element names, attribute names, and
>attribute values stand for anything?
> If so, what?
>1a) Are we assuming too much by calling the characters in
>those positions "letters"?
>2) What type, if any, are the values of the "p" attributes?
>2a) If it's some sort of numeric type, is it meaningful to
>talk about adding them?
>2b) If so, does the fact that all the p's in each t in each s,
>if interpreted as numeric, add up to
>the same value say anything about the meaning of the document?
>3) Are there any proper names other than mine, real or
>fictional, that you'd put into a search
>request if you were expecting it to turn up this document?
>4) Would the meaning of this document depend on when it was written?
>5) Does the use of whitespace in this document convey any meaning?
>6) Are any constructs in this document linked or otherwise
>related to each other?
>6) What, if anything, would you expect a "generic processor"
>to do with this document?
>
>
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://lists.xml.org/ob/adm.pl>
>
|
