Return-Path: <@FINHUTC.HUT.FI:LOJBAN@CUVMB.BITNET> Received: from FINHUTC.hut.fi by xiron.pc.helsinki.fi with smtp (Linux Smail3.1.28.1 #1) id m0r9igj-00007CC; Tue, 22 Nov 94 02:02 EET Message-Id: Received: from FINHUTC.HUT.FI by FINHUTC.hut.fi (IBM VM SMTP V2R2) with BSMTP id 9831; Tue, 22 Nov 94 02:02:37 EET Received: from SEARN.SUNET.SE (NJE origin MAILER@SEARN) by FINHUTC.HUT.FI (LMail V1.1d/1.7f) with BSMTP id 9829; Tue, 22 Nov 1994 02:02:37 +0200 Received: from SEARN.SUNET.SE (NJE origin LISTSERV@SEARN) by SEARN.SUNET.SE (LMail V1.2a/1.8a) with BSMTP id 8245; Tue, 22 Nov 1994 00:59:25 +0100 Date: Mon, 21 Nov 1994 19:03:33 EST Reply-To: jorge@PHYAST.PITT.EDU Sender: Lojban list From: Jorge Llambias Subject: Re: Cowan's summary: opacity and sumti-raising X-To: lojban@cuvmb.cc.columbia.edu To: Veijo Vilva Content-Length: 4771 Lines: 104 la lojbab cusku di'e > Of course there is nothing strange about a brivla relating two objects - a > seeker and the thing known-and-sought-after, and having a certain predicate > relating them. The problem that I see is that there is more than one such > predicate, and the choice is dependent on the specificity (or is that > definiteness %^) of x2 vs. its opacity, etc., and what the desire is of the > seeker for the final state after finding. The problem is transparency vs opacity. Transparent references can be specific or nonspecific, and that can be marked with the appropriate quantifiers, but we don't have any way to mark explicitly opaque references. The other properties that you mention, like desires of the seeker for what to do after (or rather if) the sought after thing is found, are not really to the point. If you want a place for them I guess you do need a lujvo. Also, in English, the meaning of "seek an object" has been generalized to "seek knowledge", where by "finding it", we mean that we get to know the truth value of some utterance. (I suppose that's what you call the seeking of science.) I don't have a problem with letting this metaphorical extension into Lojban, but in any case this is not part of the opaque problem. An interesting property of sisku as it is defined now, is that the lambda variable of its property really never takes a value. Normally, the lambda variable of a property corresponds to one or more of the places of the selbri (for example for {zmadu}, it's the x1 and x2) but for sisku, there is no place for the thing being sought, so there is no place that fits the lambda variable. > WE have other cases in Lojban where the Lojban word covers a misleading > subset of the English meanings of the keywords ("old" and "know" being two > cases that come to mind). BTW, because of my mail problems a month or so ago I never found out whether {citno} means "young", so that it only refers to living things, or whether it is more general. Would an "old car" in lojban be a {tolcitno karce} or a {tolcnino karce}? > In all such casesa we have learned to live with the > fact that the English word is tto broad and have come up with lujvo for the > alternative meanings. Such lujvo can always exist, and if this whole > issue of "lo" and "existence" blows away. the number of distinctions we need to > make may be reduced. But I remain unconvinced of this - as pc said a while > back in this discussion - there are some predicates that embody a hidden > abstraction involving one of the sumti, and we have to live with this What do you mean by "some predicates"? English verbs, like "want", "need", "look for", etc, or Lojban predicates like {djica}, {nitcu}, {sisku}, etc.? I totally agree that the English verbs can accept opaque references as direct objects, without any marking. They also, in other contexts, can take transparent direct objects. Because of the logical aspect of Lojban, this can't work like that in Lojban, and so the arguments are always transparent. But, the fact is that the opaque meaning is often very useful for these predicates, so what do we do? I propose to find one solution for all such predicates, rather than patches for each of them. {djica}, {nitcu} and {sisku}, for example, have all been dealt with differently: {djica} only accepts events, {nitcu} still accepts objects, and the solution for {sisku} was the weirdest: the x2 place was directly eliminated and replaced by only a property of some inaccesible entity, so that {le se sisku} is not the thing looked for, but a property of said thing. Why not treat them all the same? The transparent case: {mi djica lo tanxe} = "There is a box wanted by me" {mi nitcu lo tanxe} = "There is a box needed by me" {mi sisku lo tanxe} = "There is a box sought by me" and the opaque case: {mi djica xe'e lo tanxe} = "I want a box (I don't care which)" {mi nitcu xe'e lo tanxe} = "I need a box (I don't care which)" {mi sisku xe'e lo tanxe} = "I seek a box (I don't care which)" (I don't mind using {lo'e} instead of {xe'e lo}, I think it makes sense as well.) As things stand now, for the transparent case I have to say: {da poi tanxe zo'u mi djica tu'a da} {mi nitcu lo tanxe} {da poi tanxe zo'u mi sisku le ka du da} Why so complicated? > mi'e la lojbab noi sisku loka lo danfu be le me zo sisku me'u nabmi > cu mansa roda That doesn't make much sense to me. You probably mean {noi sisku lo ka danfu le me zo sisku me'u nabmi gi'e mansa roda}, otherwise you are saying that you are looking for something with property an answer satisfies everyone, but what is it that you look for? the answer, everyone? I think this is an unnecessarily complicated way to deal with {sisku}. Jorge