- From: Daniel LaLiberte <liberte@w3.org>
- Date: Sat, 11 Dec 1999 16:31:10 -0500 (EST)
- To: Danny Ayers <Danny.Ayers@highpeak.ac.uk>
- Cc: "www-rdf-interest@w3.org" <www-rdf-interest@w3.org>
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