Abbreviated assertions (was: Certainty Factors)

Danny Ayers writes:
 > I'm just wondering what angle the proposed RDF spec takes for dealing
 > with uncertainty, and the 'truth' of a statement. 

This is an interesting question that has come up in a number of places
recently.  I must admit that I came to RDF with the assumption that it
was more like other systems I know of, such as Lisp, where data
structures are no more than that, no assumption of truth merely because
a structure exists, except for some structures which happen to be in the
path of the evaluator.  

Now I am still trying to wrap my head around the assumption that every
RDF triple is an assertion, an expression of some implicit truth.
Questions are raised about how to represent the concept of truth itself
(explicitly), or less than certain truth, or as yet unknown truths, or
contradictory assertions, or the assertion of making some other
assertions.

In the last couple days, a few threads came together and it became clear
to me that doesn't matter whether everything is an assertion or only
some designated things (e.g. code, inference rules, starting
assumptions, etc).  The main reason is that what matters is what you
*do* with assertions, and that is the real semantics.  We can assert
some things and use those along with inference rules (and, importantly,
an interpretor) to derive any other assertions we need (or the ones we
really meant).

In general, we can represent a complex graph of relationships with a
very simple graph, a tree even, if we have a set of inference rules
which allow us to transform the simple representation into the complex
one.  Both representations may be just as "true" in the sense of being
RDF assertions.  The simple representation may require more
"interpretation" to get to the useful relationships expressed directly
in the complex representation, but there is value in simple
representations for communication.

To illustrate a relatively simple case, consider the following nodes, A,
B, and C, and properties p and q.  These might be in the following not very
complex graph:

A --p--> B --q--> C

But we can instead define a new property, call it 'p-q', that relates 
A and C such that both B and C are related directly to A:

A --p--> B
A --p-q--> C

And from that, and the obvious inference rule, we can infer the triple:
B --q--> C.  This is a relatively simple case, but you can easily
imagine a more complex case with many more nodes and many more inference 
rules.  The general case might be expressed:

A --p1--> B1
A --p2--> B2
A --p3--> B3
 ...
A --pn--> Bn

This is directly analogous to a sequence or a tuple of distinguished
values (B1, B2, B3, ... Bn) with a meaning associated with A.  We might
define this 'A tuple' to mean that

B1 --q1--> B2 --q2--> Bn
etc.


As another example, the idea of reification in RDF is confusing to
people, and somewhat troublesome, but with an abbreviated notation, this
might help make it more understandable.  The reified form of an RDF
triple (S, O, P) is a node R with four properties:

R --Subject--> S
R --Object--> O
R --Predicate--> P
R --type--> Statement
 
Notice the parallel with the tuple package above, and we might express
it in tuple notation as Reified(S, O, P).   But we can also represent this
as a single triple of the form:

S --Reified(P)--> O

where "Reified(P)" is a new property which "asserts" or "implies" or
"means" that we should create the above triples of the reified form.
One problem is that in the abbreviated form, we don't have an expicit R
to refer to directly so we could relate the reification to other things.


This argument about how you can express assertions that represent
reifications is independent of how you might implement reification in an
application, or standardized in an API.   But it is interesting that
we want to make such abbreviations all the time.

---

Given this argument that it doesn't matter whether everything is
considered an assertion, because the real semantics lies in how we
interpret any particular set of assertions, then we still need
vocabularies with the meaning defined informally in specs or more
formally in logic languages.  Without all that additional semantics, RDF
model is just a way of representing graph structures, and the current
RDF syntax is just a not-particularly-easy-to-use representation of such
graph structures.  RDF Schemas give us a small set of additional
semantics, but there is a lot more to come.


-- 
Daniel LaLiberte
liberte@w3.org

Received on Saturday, 11 December 1999 16:31:14 UTC