Re: Abbreviated assertions (was: Certainty Factors)

Danny Ayers writes:
 > You say '...what matters is what you *do* with assertions...' which
 > seems a little to be avoiding my question.

Right. I must apologize for going off on a tangent inspired by your
message, and neglecting to tie it back to what you said.  It is related,
and even more so after your reply.  I've actually been thinking about
this problem of uncertainty from a number of perspectives, and these
related problems of "where's the truth?" and the semantics of assertions
came to the fore recently.

 > ... you are meaning something along the lines of :
 > 
 > A --p--> B
 > 
 > could be
 > A = Freddy's cat
 > p = has colour
 > B = Red
 > 
 > B --q--> C
 > 
 > B = Red
 > q = type of colour
 > C = Primary
 > 
 > which could allow us to have 
 > 
 > A --p--> x --q--> C
 > 
 > so I suppose --p-q--> could be equal to --p--> x --q--> 
 > 
 > which is clear given the above example, but I'm not clear enough to see
 > whether this can be generalised. 

Yes, this is p-q relation is what I was talking about, but it can be
used either as an abbreviation for the p and q relations, or the other
way around, where p and q relations could be used to infer the p-q
relation.  In other words, it doesn't matter how you express a set of 
relations between objects as long as you have all the objects separately 
identifiable in some sufficient relation relative to a context or package
(e.g. a tuple).  The same idea applies to probabilistic relationships,
and the question of what you do with them is the same.  To do
probabilistic logic, you would need the appropriate logic engine to
interpret the relationships as you intend.

 > But I'm slipping off my topic, so for the sake of argument let's say the
 > above is all fair enough, then as the assertions have no element of
 > uncertainty, then whatever you do with the assertions is fixed to this
 > same premise. If however you had the following 
 > A --p--> B (probability 0.9)
 > B --q--> C (probability 0.9)

 > you could derive a probability for A --p-q--> C, so you could say 'there
 > is a 0.81 (or somesuch) probability that Freddy's cat is a primary
 > colour.
 > 
 > To keep with the 'assertions-only' approach I imagine this could be
 > expressed as :
 > 
 >         [s1] - type -> rdf:Statement 
 >         [s1] - subject -> [Freddy's Cat]
 >         [s1] - predicate -> [colour]
 >         [s1] - object - > [Red]
 > 
 >         [s2] - type -> rdf:Statement 
 >         [s2] - subject -> [s1]
 >         [s2] - predicate -> [certainty]
 >         [s2] - object - > [0.9]
 > 
 > but I was wondering whether this is adequate to cover all eventualities.
 > Is a rdf:Statement(probabilistic) type needed? Is there a better way of
 > expressing [s2]?

If you want the uncertain relationships to live in the same world as the
certain ones, then since RDF assertions are of the certain variety, you
would have to do as you suggest and express an uncertainty using the
reified form of the assertion.  But s2 would not, itself, have to be in
the reified form.  It is OK to assert: [s1] --certainty--> [0.9] because
that assertion about the uncertainty of another assertion is itself
certain.

My bit about abbreviating the reification of an assertion applies here
too, but it doesn't help because you need to have a separate node (not
the node for freddy's cat or the color red) to attach the probability,
so it amounts to almost the same number of arcs as the reified form.
Call this node 'ab'.

ab -- subject --> [Freddy's cat]
ab -- predicate --> [color]
ab -- object --> [red]
ab -- probability --> [0.9]

But this form is actually better than using the reified form directly
because someone else might want to attach a different probability to the
same reified form.  The term "probability" may mean exactly the same
thing in both cases so it may not make sense to use different terms, but
each probability value may have been computed by a different method or
using the same method but at different times.  So it seems better to
associate the probability with an independent node.

-- 
Daniel LaLiberte
liberte@w3.org

Received on Monday, 13 December 1999 14:48:17 UTC