headers
Hamish Harvey | 1 Oct 2005 12:55

Re: Evolution of Language

On Friday 30 September 2005 02:57, Jean-Luc Delatre wrote:
> On Thu, 29 Sep 2005 22:57:20 +0100
>
> Hamish Harvey <hamish@...> wrote:
> > What about
> >
> > {"the sum of X and Y",  "the product of X and Y"}
> > {"add X and Y", "multiply X by Y"}
>
> No two such classes.

Their contents seem to me to just as similar/dissimilar as the original two:

{"the sum of X and Y",  "add X and Y"}
{"the product of X and Y", "multiply X by Y"}

"the sum of" is a result. "add" is an action. The connection in each case that 
one member of the class refers to the result of the other. The statements are 
not semantically equivalent, just related.

The members of two classes I suggest are clearly similar in syntactic 
structure. They also have semantic similarity: the result of applying an 
operator to two values, and the action of doing so. So these seem to me to be 
equally valid "equivalence classes".

> But all 4 items may be part of a "more general" "class" of binary
> arithmetic operations. The overall structure of "all classes" being akin to

The "more general" "class" seems to have do with the notion of binary 
arithmetic operations, abstracting away not only from the specific operator,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jean-Luc Delatre | 1 Oct 2005 19:43
Picon

Re: Evolution of Language

Hi Hamish,

Nice to you to give me the opportunity to refine my thoughts but bear in mind that I DON'T HAVE a "detailed
account of how exactly this thing is going to work".
Neither me, you or anyone else is going to begin the implementation of something "like this" in the next few weeks.
If for any project the "grand plan" and "final blueprint" were to magically appear out of thin air in a snap
there will be no need for the process we call *design*, though there IS such a thing isn't it?

> > > {"the sum of X and Y",  "the product of X and Y"}
> > > {"add X and Y", "multiply X by Y"}
> >
> > No two such classes.
> 
> Their contents seem to me to just as similar/dissimilar as the original two:
> 
> {"the sum of X and Y",  "add X and Y"}
> {"the product of X and Y", "multiply X by Y"}
> 
> "the sum of" is a result. "add" is an action. The connection in each case that 
> one member of the class refers to the result of the other. The statements are 
> not semantically equivalent, just related.

Right!
First I would like to get rid of the temporary denomination "equivalence class", let's replace it by
"concept", still in quotes because again it will not be quite identical to what floats around the usual
acception of the word concept, just somewhat close.
I had initially choosen "equivalence class" to emphasize the fact that all "members" would *more or less*
mean the same, yet I warned that this was NOT truly an equivalence class and it would even have "fuzzy
boundaries", that is that some members would only *remotely* ressemble the core members.
Also the very idea of "AN" equivalence class implies that only a single "equivalence relation" is used to
(Continue reading)

Permalink | Reply | 0 comments |
headers
John F. Sowa | 2 Oct 2005 23:02

Re: Annex B of ISO 24707

Harry,

I'm working on Annex B, and I'll have it finished by
the end of Oct.  I'll put an updated (but incomplete)
version on my web site next week.

Re actors:  I plan to define an actor as a relation
that satisfies the functional axiom for each of
its output arcs.  In DB terminology, the input arcs
represent the key of a relation, and the output arcs
are functionally dependent on the key.

I'll also take into account the recent discussions
on CL list about functions and relations.  As the CGIF
notation for actors, there has been some concern about
the conflicts of using "<" and ">" in XML.  Therefore,
I suggest the following notation for CGIF actors:

    (Name in-arc1 ... in-arcN; out-arc1 ... out-arcM)

A CLIF function would be represented by an actor
with just one output arc (i.e., M=1).  An ordinary
CL or CGIF relation would be an actor with M=0.

But I do have a problem with CGIF actors with M>1.
My current feeling is to allow actors to have a
variable number of input arguments if M=0 or 1.
But if M>1, then both N and M must be constants.

Re comments:  We discussed this before, and I'd be happy
(Continue reading)

Permalink | Reply | 1 comment |
headers
Harry Delugach | 3 Oct 2005 01:24

Re: Re: Annex B of ISO 24707

For those of you on the CG list, ISO 24707 is the entire Common Logic  
standard, of which CGIF is a part (Annex B). See http://cl.tamu.edu  
for more details and the current text of the document.

On Oct 2, 2005, at 5:02 PM, John F. Sowa wrote:

> Harry,
>
> I'm working on Annex B, and I'll have it finished by
> the end of Oct.  I'll put an updated (but incomplete)
> version on my web site next week.

Thanks -- I'll need to get the finished version into ISO's form  
immediately thereafter, so that can be considered a hard deadline.  
I'd like to point out that any discussion will need to place BEFORE  
Oct 31st, not AFTER -- because at that time I'll have to "carve it in  
stone" which will make changes much more painful afterward.

>
> Re actors:  I plan to define an actor as a relation
> that satisfies the functional axiom for each of
> its output arcs.  In DB terminology, the input arcs
> represent the key of a relation, and the output arcs
> are functionally dependent on the key.

I'm not especially concerned about the DB notation, particularly  
since in the way I use actors for databases, there is only one real  
"key" (i.e., primary key) -- the rest are field names. I couldn't  
tell if you're planning to use the DB terminology in the Annex, but  
I'd suggest avoiding it if possible.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Avril Styrman | 3 Oct 2005 14:21
Picon
Picon

Re: Evolution of Language

Quoting Jean-Luc Delatre <jld@...>:

> The kludginess of fuzzy logic comes from NOT GOING FAR ENOUGH in trying
> to "accommodate the continuous nature of the phenomenal world".
> The membership is scaled over the real interval [0-1] but the objects and
> properties are *still discrete*.
> We need to have a fully continuous representation where the "objects" and
> "properties" will just be more "dense spots" within some representation
> space.
> The "discrete" objects and properties we are used to being only "very
> noticeable" spots (salient!)

In CYCLanguage, also the domain of a fuzzy logic statement can be specified,
i.e., the semiotic definitions of the "continuous nature of the phenomenal
world" are possible. That is one thing, but getting some benefit out of that
representation is something else.

I don't claim that only fuzzy logic would serve as some sort of über
solution to AI, and who would? Fuzzy logic is anyway needed anyway as an
idea that nothing is crisp, and also practically to specify fuzzy memberships. 

Claiming that fuzzy logic is only a kludge is like claiming that toilet
paper or a fork is only a kludge. What do you think is not a kludge? Give an
example of a succesfull system that is not a kludge, or are there any? 

Avril
========================
To post a message, send mail to cg@...
To unsubscribe, send mail to majordomo@... with the command
'unsubscribe cg' in the message body.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jean-Luc Delatre | 3 Oct 2005 19:15
Picon

Re: Evolution of Language

On Mon,  3 Oct 2005 15:21:07 +0300
Avril Styrman <Avril.Styrman@...> wrote:

> In CYCLanguage, also the domain of a fuzzy logic statement can be specified,
> i.e., the semiotic definitions of the "continuous nature of the phenomenal
> world" are possible. 

The documentation from Cycorp specifically says that Cyc inferences are NOT based on fuzzy logic!

"the basis of our system is not Bayesian Reasoning or fuzzy logic or something like that. for every
Inference step We make, We actually have a logically-sound proof behind it that you can look at to see  'X is
true specifically because I did a deduction and Y and Z are the two things which together allow me to
conclude it.' "

Page 5 of: http://www.cyc.com/doc/tut/DnLoad/InferenceLogicalAspects.pdf

So, what do you mean by "the domain of a fuzzy logic statement can be specified"?
Is this "domain" continuous or discrete?
And how would that make 'the semiotic definitions of the "continuous nature of the phenomenal world" []
possible.' ?

Anyway it doesn't look like you are grasping the meaning of a "fully continuous representation of objects".

This means that "objects" (or rather objects names or references), instead of being an enumerable
sequence of identifiers like the integers would be points in a space of so many continuous dimensions and
that a "metric" of some sort or even a function wich would *not* be a metric will be used to "compare" objects
for similarity or relatedness according to varying criteria.
Our familiar objects, concepts and properties being only "spots" inside this representation space.
How many dimensions to this space, how to define the appropriate function or functions, how to "project"
this space to various subspaces in order to "extract" the properties of interest for any given
(Continue reading)

Permalink | Reply | 2 comments |
headers
Harry Delugach | 3 Oct 2005 20:37

Re: [CL] Re: Annex B of ISO 24707


On Oct 3, 2005, at 11:57 AM, Heather D. Pfeiffer wrote:

>
> Harry, John, etc.
>
>>>
>>> I'll also take into account the recent discussions
>>> on CL list about functions and relations.  As the CGIF
>>> notation for actors, there has been some concern about
>>> the conflicts of using "<" and ">" in XML.  Therefore,
>>> I suggest the following notation for CGIF actors:
>>>
>>>    (Name in-arc1 ... in-arcN; out-arc1 ... out-arcM)
>>>
>>
>> I think this is a holdover from the expectation that XML would be the
>> primary notation and that CGIF would have to be embedded in XML. This
>> is no longer the case, as I understand it. If your example is meant
>> to be in CLIF form, then the semicolon is not legal CLIF syntax (I
>> don't think).
>>
>>
>  I would make the following suggestion written in Annex B format:
>
>    Arc ::= Concept | BoundLabel
>
>    In-Arc :: Arc
>
>    Out-Arc :: Arc
(Continue reading)

Permalink | Reply | 3 comments |
headers
Heather D. Pfeiffer | 3 Oct 2005 22:43

Re: [CL] Re: Annex B of ISO 24707


Harry,

Harry Delugach writes:
 > 
  <cut>
 > >  I would make the following suggestion written in Annex B format:
 > >
 > >    Arc ::= Concept | BoundLabel
 > >
 > >    In-Arc :: Arc
 > >
 > >    Out-Arc :: Arc
 > >
 > >    Actor ::= "(" Type(N) In-Arc* "|" Out-Arc* Comment? ")"

                                                 ^ this can be 1 to
                                                 many

 > >
 > >  where relation would be:
 > >
 > >    Relation ::= "(" Type(N) In-Arc* "|" Out-Arc Comment? ")"
 > >
                                                   ^ this can only be
                                                   1

 > >  From this perspective a relation would have a single output arc and
 > >  an actor could have several.  However, this does not indicate that an
 > >  actor is a "function" when only having one Out-Arc, but would be a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ulrik Petersen | 3 Oct 2005 22:57

Re: [CL] Re: Annex B of ISO 24707

Harry,

Harry Delugach wrote:

>
> On Oct 3, 2005, at 11:57 AM, Heather D. Pfeiffer wrote:
>
>>
>> Harry, John, etc.
>>
>>>>
>>>> I'll also take into account the recent discussions
>>>> on CL list about functions and relations. As the CGIF
>>>> notation for actors, there has been some concern about
>>>> the conflicts of using "<" and ">" in XML. Therefore,
>>>> I suggest the following notation for CGIF actors:
>>>>
>>>> (Name in-arc1 ... in-arcN; out-arc1 ... out-arcM)
>>>>
>>>
>>> I think this is a holdover from the expectation that XML would be the
>>> primary notation and that CGIF would have to be embedded in XML. This
>>> is no longer the case, as I understand it. If your example is meant
>>> to be in CLIF form, then the semicolon is not legal CLIF syntax (I
>>> don't think).
>>>
>>>
>> I would make the following suggestion written in Annex B format:
>>
>> Arc ::= Concept | BoundLabel
(Continue reading)

Permalink | Reply | 1 comment |
headers
Heather D. Pfeiffer | 3 Oct 2005 23:38

Re: [CL] Re: Annex B of ISO 24707


Ulrik Petersen writes:

  Thank you.  I am at a conference and could not get that reference.
 Thank you again.

-Heather

 > Harry,
   <cut>
 > >>
 > >> I would disagree that a relation is an actor with zero output arc; a
 > >> relation needs at least one output. Could you possibly indicate a
 > >> relation that had no output.
 > >
 > >
 > > The arrow on a relation in CG's is completely arbitrary, 
 > 
 > 
 > 
 > This is actually not true. See Dr. Sowa's KR book, p. 479, which I quote 
 > here:
 > 
 > "For a conceptual relation with n arcs, the first n-1 arcs have arrows 
 > that point toward the circle, and the n-th or last arc points away."
 > 
 > You can also see our teaching materials from the University of Aalborg, 
 > although they are not authoritative:
 > 
 > http://www.huminf.aau.dk/cg/Module_I/1036.html
(Continue reading)

Permalink | Reply | 0 comments |

Gmane