- From: Trevor Martin <Trevor.Martin@bristol.ac.uk>
- Date: Fri, 20 Jul 2007 09:04:14 +0100
- To: public-xg-urw3@w3.org
On 19 Jul 2007, at 13:36, Umberto Straccia wrote: > > > On Jul 19, 2007, at 10:22 AM, Trevor Martin wrote: > >> This is precisely the choice faced by implementers of logic >> programming + uncertainty languages .... you can extend the >> language and the inference mechanism or express and process the >> uncertainty within the standard language. >> >> tall(John) : 0.7 >> >> vs >> >> tall(John, 0.7) >> >> (... in both cases, without saying what 0.7 represents) >> >> The former approach gives you more control, reduces to "standard" >> notation when the uncertainty is omitted and (I think) makes the >> semantics clearer; >> the latter involves no change to existing notation (hence is >> easier to sell ) but gets messy when only some of the >> representation requires the uncertainty and obscures the meaning >> of the annotation. >> > > Not exactly, Trevor. What should be a minimal setting (you know > that there are 200+ citations about Logic Programming, uncertainty/ > vagueness ....) be ? What semantics? I was trying to avoid (for the time being) the question of what the number (or annotation) means > > Even an expression of the form > > P(c1, ...cn): 0.7 > > is open to a pletora of semantic options ... > > What I say is is that > >> tall(John) : 0.7 > > should rather be represented like (guided by the uncertainty ontology) > > sentence s IS tall(John) AND s HasTruthDegree = 0.7 > > Anyway, that's just my opinion ... > > I think this is the second option I mentioned - effectively you say R1(X, Y) AND R2(X, Z) where X = sentence s, R2 = HasTruthDegree, etc This doesn't give any special status to HasTruthDegree. I'm not disagreeing, just trying to clarify things in my own mind .... Trevor > > >
Received on Friday, 20 July 2007 08:03:35 UTC