>on Tue. Dec. 25, 2007 at 2:23 AM, Pat Hayes wrote:
>>
>>>on Mon Dec 24, 2007 at 4:18 PM, Pat Hayes wrote:
>>>
>>>> >Please forgive me, in advance, for my spotty knowledge of some
>>>>of the >topics
>>>>>in this post. My interest in these ideas often exceeds my understanding.
>>>>>
>>>>>First, congratulations to all on the ISO adoption of CL as a standard. I
>>>>>believe it will prove to be an invaluable addition to the spread of
>>>>>interoperable knowledge representation technology. It is an important
>>>>>achievement. I am doubly excited by this because it includes, at
>>>>>long last,
>>>>>an ISO standard for Conceptual Graphs. CGs was the first knowledge
>>>>>representation formalism I encountered. I read the CG1984 book several
>>>>>times, worked on an implementation in prolog of a linear form,
>>>>>and then had
>>>>>the pleasure to participate for a short time in 1997 on work towards the
>>>>>CGIF standard specification. More recently, having decided that
>>>>>semantics is
>>>>>heavily dependent on contexts, and searching for material concerning that
>>>>>subject, I came across IKL and the startling claim that "Every
>>>>>occurrence of
>>>>>an IKL name has the same meaning." This is something I find highly
>>>>>desirable, but which as I said, I had just recently decided was not
>>>>>possible.
>>>>
>>>>I think you may be reading more into this than was intended. It
>>>>does not say that every occurrence of an IKL name has the same
>>>>unique referent in the actual world. It says that every such name
>>>>occurrence maps to referents in all interpretations in the same
>>>>way. But there may be many possible interpretations: there almost
>>>>always are.
>>>
>>>I'm confused. I understand that there may be many interpretations.
>>>Lets consider the case of two network nodes. If the referent of a
>>>name 'A' is X in one interpretation and is Y in another
>>>interpretation, then in what sense are these name occurrences
>>>mapped "...in the same way."? From what you say later, I suppose
>>>you mean that all the same statements are true of both X and Y.
>>
>>Yes, quite correct. What that puzzling phrase means is only that
>>the WAY that the interpretation mappings are applied is uniform
>>across all occurrences of names. To see what this means, consider
>>some cases where this would fail to be true.
>>
>>1. If the logic has modalities such a a future tense operator F,
>>then the meaning of a name (in fact, any referring term) may be
>>different inside the scope of the modality from its meaning
>>outside. Suppose for example we introduce a name [note A]
>>PresidentOfUSA, so that (= PresidentOfUSA GeorgeWBush) is true now;
>>but it is certainly not true now that (F 2010 (= PresidentOfUSA
>>GeorgeWBush)), because the referent of "PresidentOf USA" will be
>>different in 2010.
>>
>>2. If the logic has contexts which affect the denotation of names,
>>then the same name may be interpreted differently in different
>>contexts. (Not all context logics allow names to denote differently
>>in this way, but some do.)
>
>And this is clearly a part of IKL. (01)
No. IKL is what you get when you take CL and add the ability to
denote *propositions*. It turns out that this enables you to have the
expressivity (in fact, in many case rather more) that modal and
context logics provide, without sacrificing the 'name transparency'
property of CL itself, that every occurrence of a name is treated the
same as every other occurrence. But IKL is not a context logic, and
contexts do not affect the denotations of names in IKL. (02)
>Is the modality and context logic mapping functionality in IKL due
>to something in CL? (03)
No. It arises from the 'extra' feature in IKL, the proposition name
construction (that <sentence>), which is not in CL. (04)
>Or is this part of the IKL dialect? (05)
IKL isn't a dialect of CL. (Well, strictly, it could be, but only by
declaring every sentence which contains a proposition name to be
irregular, which kind of shoots the logic in the head.) (06)
> A related question: Is IKL considered to be an ISO standard (07)
Nope. (08)
>by virtue of its being conformant to the CL dialect forming feature in CL? (09)
It would be, but it doesn't conform to that feature (other than by
the total emasculation process just noted). (010)
>Or will it need to go through a standardization process also? (011)
I don't think it is anywhere near time to talk of standardizing a
logic this close to the research leading edge, whose properties are
not even fully examined theoretically yet and which nobody has yet
implemented. (012)
>
>>3. If the logic is used to encode temporally sensitive data, then
>>what a name denotes can change with actual time, so that archived
>>information may contain names which now no longer denote what their
>>'current' values are.
>
>I had thought that time was yet another type of context. Is it
>different somehow? (013)
You CAN treat time as a context, if you like contexts. But that is
not the only way to tackle a logic of time: the modal temporal logics
pre-date context logics by about 60 years. (014)
>>4. If the same name is used in several ontologies widely separated
>>or built independently using a conventional FOL syntax or OWL-DL,
>>then one of them might use it to name an individual, while another
>>might use it to name a relation (in FOL) or a class (in OWL-DL),
>>producing a syntactically illegal situation when these ontologies
>>are merged, since these logics require names to be strictly
>>segregated according to what they are allowed to denote. (This
>>situation, and finding a uniform way to avoid it, was one of the
>>leading motivations for the CL design, in fact.)
>
>Do you mean that CL has features which allows these illegal situations (015)
I'm saying that these situations *aren't illegal* in CL. Their
apparent 'illegality' is an artifact of the limited and overly
protective syntactic frameworks that have traditionally been used for
formal logical descriptions. (016)
>to be dealt with post-hoc or is this something that must be done up
>front using CL cooperatively? (017)
In a sense: but no cooperation is required other than both ontologies
being written in CL. (018)
>It looks to me like what is done is that CL allows for both
>ontologies to be translated to CL and then merged legally. (019)
That is one way to put it. I think it would be better if they were
written in a CL dialect in the first place, myself. (020)
>This would still leave work to be done to make the two groups of
>sentences work together, wouldn't it? (021)
Depends what you mean by "work together". In a broad sense, of course
one will usually need to do some work to make two ontologies work
well together, yes. But if they are both written in CL, then one will
probably have a lot less low-level grunt work to make them at least
*syntactically* compatible. At the moment, if they are both written
in OWL-DL, there is a good chance that their union cannot even be
parsed by the current OWL-DL software. This cannot happen with CL:
the union or concatenation of any two legal CL texts is itself a
legal CL text, and the two subtexts retain their meanings
independently from the presence of the other. Moreover, the syntactic
freedom that CL (strictly, any nonsegregated CL dialect, such as
CLIF) provides makes it much easier to write "bridge axioms" which
describe the relationships between concepts in different ontologies,
such as how to translate one temporal convention into another. (Its
even easier in IKL, which was the point of IKL in the first place.) (022)
>>>>>The topic I am particularly interested in discussing here now,
>>>>>is this claim
>>>>>and a similar statement in the CL requirements section 5.1.4.b.,
>>>>>"Any piece
>>>>>of Common Logic text should have the same meaning, and support the same
>>>>>entailments everywhere on the network. Every name should have the same
>>>>>logical meaning at every node of the network."
>>>>
>>>>Right. Note, *logical* meaning. One might reasonably say that the
>>>>meaning of "Patrick J Hayes" is me, in this particular world, but
>>>>that is not its logical meaning. Its logical meaning is a mapping
>>>>from interpretations (aka possible worlds) to an individual in
>>>>that interpretation's universe.
>>>
>>>I have never gotten comfortable with the idea of sorts or types of
>>>meaning (formal, social, natural, logical, etc. etc.).
>>>Never-the-less, I take you mean that the requirement is that the
>>>same set of statements will be true of all referents of the name
>>>in all interpretations
>>
>>Yes. And of every *occurrence* of the name, is the point. CL and
>>IKL treat every *occurrence* of a name in the same way, wherever it
>>occurs. Many logics do not. In fact, most logics do not.
>
>So we would say, "...the same set of statements will be true of all
>referents of each occurrence of the name in all interpretations."?
>Then you are saying that most logics treat the separate occurrences
>of a name as though there were only one occurrence? (023)
Yes, in a sense. The semantics refers to a (single) mapping from
names to individuals, one such mapping for each interpretation. And
yes, *every* occurrence of a given name is mapped by this mapping to
one single thing in the universe. (024)
>Reminds me of a question I keep having with regard to URIs in the
>Web Architecture. There doesn't seem to be any attempt to
>distinguish between each occurrence (I sometimes call it an
>utterance) of a URI and its establishment. (025)
Indeed, there is not. On the contrary, there is an insistence that no
such distinction be made. To make it is an architectural error. That
is the whole point of URIs, if you think about what they are mostly
used for. If your browser, in its context, were to interpret a URI
differently from the website it identifies, in its context, then the
entire Web would stop working. (026)
> And in fact, it seems to be argued often that this is by design and
>intentional, yet nowhere is are there methods for dealing with what
>seems to be inevitable contextual differences between each
>occurrence of a URI. (027)
That is exactly the point. There should not be any such contextual
differences. The CL logic is designed to eliminate them. If they, as
you say, 'inevitable', then the Web must be broken. But on the whole
it seems to work reasonably well. (028)
>In other words, it sounds like IKL aims for the same goal (029)
IKL and CL are similar in this aspect, of having globally transparent
meanings for names. (030)
> but includes some machinery for achieving it, while the Web
>Architecture claims that it is so by engineering design. (031)
Well, URIs on the Web have a dual aspect: they provide access to
"information resources" (for the meaning of this jargon, go to the
W3C) and they also are used in RDF and OWL to *denote* arbitrary
things. The relationships between these two roles are subtle and
controversial, and not always described very clearly. But certainly,
both the Web architecture and the CL logic assume that names denote
uniformly, not differently in different 'local contexts'. (032)
> Fair characterization? (033)
Bit too simple, but getting there. (034)
>>>, not that the name will necessarily have the same referent in all
>>>interpretations.
>>
>>Not that, no. In fact that isn't even meaningful, since the
>>universes of two interpretations may be disjoint.
>
>But then what do other logics claim? How do they put it? You said
>before that most logics do not treat each occurrence of a name
>differently. (035)
? Im not sure what you are asking about here. That remark about
interpretations applies to all logics with a Tarskian or Kripkeian
semantics, which is pretty much all logics. (036)
Pat
--
---------------------------------------------------------------------
IHMC (850)434 8903 or (650)494 3973 home
40 South Alcaniz St. (850)202 4416 office
Pensacola (850)202 4440 fax
FL 32502 (850)291 0667 cell
phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes (037)
_________________________________________________________________
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 (038)
|