From nobody@digitalkingdom.org Fri Apr 08 15:24:47 2005 Received: with ECARTIS (v1.0.0; list lojban-list); Fri, 08 Apr 2005 15:24:47 -0700 (PDT) Received: from nobody by chain.digitalkingdom.org with local (Exim 4.44) id 1DK1u3-0006ux-PB for lojban-list-real@lojban.org; Fri, 08 Apr 2005 15:24:39 -0700 Received: from n20a.bulk.scd.yahoo.com ([66.94.237.49]) by chain.digitalkingdom.org with smtp (Exim 4.44) id 1DK1u1-0006uR-2U for lojban-in@lojban.org; Fri, 08 Apr 2005 15:24:39 -0700 DomainKey-Signature: Received: from [66.218.69.6] by n20.bulk.scd.yahoo.com with NNFMP; 08 Apr 2005 22:24:01 -0000 Received: from [66.218.66.36] by mailer6.bulk.scd.yahoo.com with NNFMP; 08 Apr 2005 22:24:01 -0000 X-Yahoo-Newman-Property: groups-email X-Sender: ben@goertzel.org X-Apparently-To: lojban@yahoogroups.com Received: (qmail 89297 invoked from network); 8 Apr 2005 22:23:59 -0000 Received: from unknown (66.218.66.216) by m30.grp.scd.yahoo.com with QMQP; 8 Apr 2005 22:23:59 -0000 Received: from unknown (HELO intelligenesiscorp.com) (208.234.8.229) by mta1.grp.scd.yahoo.com with SMTP; 8 Apr 2005 22:23:59 -0000 Received: from zombiethustra (pcp06586041pcs.nrockv01.md.comcast.net [69.140.24.121]) by intelligenesiscorp.com (8.12.10/8.12.10) with SMTP id j38MNii3015061; Fri, 8 Apr 2005 18:23:45 -0400 To: "Ben Goertzel" , Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Originating-IP: 208.234.8.229 X-eGroups-Msg-Info: 1:12:0 From: "Ben Goertzel" X-Yahoo-Profile: bgoertzel MIME-Version: 1.0 Mailing-List: list lojban@yahoogroups.com; contact lojban-owner@yahoogroups.com Delivered-To: mailing list lojban@yahoogroups.com Precedence: bulk Date: Fri, 8 Apr 2005 18:24:00 -0400 Subject: [lojban] Semantics of lojban and glibau, and Lojban FrameNet revisited Content-Type: multipart/alternative; boundary="----=_NextPart_000_021A_01C53C68.22B3C800" X-Spam-Score: -2.5 (--) X-archive-position: 9795 X-ecartis-version: Ecartis v1.0.0 Sender: lojban-list-bounce@lojban.org Errors-to: lojban-list-bounce@lojban.org X-original-sender: ben@goertzel.org Precedence: bulk Reply-to: lojban-list@lojban.org X-list: lojban-list ------=_NextPart_000_021A_01C53C68.22B3C800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sorry to reply to myself again... I suppose in this case the asymmetry of the semantics of "Lojban" versus "English" in Lojban can be worked around easily via e.g. .i la lojban HYP glibau but that doesn't really solve the problem of "lojban" being a cmene versus "glibau" being a predicate with arguments, which seems an odd asymmetry to me... This ties in with something I've thought about before: the need for some kind of ontology of argument-structures (which would be part of what I called a Lojban FrameNet in www.goertzel.org/new_research/lojban_AI.pdf ) Shouldn't there be something like _bangu (meaning a set of predicates with the same argument structure, all reflecting types of bangu ("language")) Here Member(x, _bangu) for any predicate x would imply arg1 is the x language, used by arg2 to communicate arg3 Then instead of explicitly articulating the argument structure for all the words indicating all the different languages, one would simply have to say something like "The following are members of _bangu: glibau lojbanu chinese [whatever the lojban word for that is] ... etc. " Taking this kind of approach to defining argument structures would seem to reduce the risk of odd inconsistencies occurring in the dictionary of argument-structures... I'm curious why a systematic approach like this wasn't taken in constructing the Lojban dictionary, since Lojbanoidic folks seem so interested in order and systematicity... it's odd that the argument-structures are only imperfectly and informally systematized, no? -- Ben G I don't like .i la lojban HYP mintu le glibau because this is a posited equivalence between two entities of different types, it seems semantically incorrect even though it may (?) be syntactically allowable. ------=_NextPart_000_021A_01C53C68.22B3C800 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
Sorry to reply to myself again...
 
I suppose in this case the asymmetry of the semantics of "Lojban" versus "English" in Lojban can be worked around easily via e.g.
 
.i la lojban HYP glibau
 
but that doesn't really solve the problem of "lojban" being a cmene versus "glibau" being a predicate with arguments, which seems an odd asymmetry to me...
 
This ties in with something I've thought about before: the need for some kind of ontology of argument-structures (which would be part of what I called a Lojban FrameNet in www.goertzel.org/new_research/lojban_AI.pdf )
 
Shouldn't there be something like
 
_bangu
 
(meaning a set of predicates with the same argument structure, all reflecting types of bangu ("language"))
 
Here
 
Member(x, _bangu)
 
for any predicate x would imply
 
arg1 is the x language, used by arg2 to communicate arg3
 
Then instead of explicitly articulating the argument structure for all the words indicating all the different languages, one would simply have to say something like
 
"The following are members of _bangu:
glibau
lojbanu
chinese [whatever the lojban word for that is]
... etc.
"
 
Taking this kind of approach to defining argument structures would seem to reduce the risk of odd inconsistencies occurring in the dictionary of argument-structures... I'm curious why a systematic approach like this wasn't taken in constructing the Lojban dictionary, since Lojbanoidic folks seem so interested in order and systematicity... it's odd that the argument-structures are only imperfectly and informally systematized, no?
 
-- Ben G
 
 
 
 
I don't like
 
.i la lojban HYP mintu le glibau
 
because this is a posited equivalence between two entities of different types, it seems semantically incorrect even though it may (?) be syntactically allowable.
 


To unsubscribe, send mail to lojban-unsubscribe@onelist.com


Yahoo! Groups Links
------=_NextPart_000_021A_01C53C68.22B3C800--