- From: Graham Klyne <GK@NineByNine.org>
- Date: Fri, 15 Mar 2002 22:23:40 +0000
- To: "Seth Russell" <seth@robustai.net>
- Cc: "RDFIG" <www-rdf-interest@w3.org>
At 12:28 PM 3/15/02 -0800, Seth Russell wrote: >From: "Graham Klyne" <GK@NineByNine.org> > > > Example: > > A says { B says {C says D} . B a liar } . > > If I decide that what A says is true, I may enter the context of > > what A says and assert: > > B says {C says D} . B a liar . > > If we have a syntactic construct for containment, as N3, then the contents > > of {...} can be treated opaquely as you suggest. But when all this is > > encoded into a flat space of triples, some other mechanism is needed. I >am > > proposing (multiple levels of) encoding as reification-quads. > >Well I think that coding a triple as the RDF reification quad makes it >default to being opaque (not necessarialy true) in every context ... in >other words a reified statement is simply not asserted in any context. Yes. > If we want the statement to be true in some context we will need to > invent a >property that asserts in that context. I was presuming a very general technique: one "enters" a context by performing one level of "unreification" -- create a new graph with each rdf:Statement resource in the context generating a statement (triple) containing the corresponding subject, object and property. Using my scheme, inner nested contexts still appear as reification quads. The top level statements of the context entered come out as (non-reified) statements, hence asserted. > N3 seems to do that implicitly: {B >a liar. {inner nested context}} means that inside the first {} 'B a liar' is >true, but what is in the {inner nested context} is not necessarily true. >When we project that back to simple triples we would need to explicitly >state the knowledge that 'B a liar' is true in the first outer context. Well, yes, I think. In this proposal I'm trying to make that "implicit" mechanism of N3 explicit in RDF. (I think this is easy with N3 precisely because it has a syntactic nesting structure). #g ------------------- Graham Klyne <GK@NineByNine.org>
Received on Friday, 15 March 2002 17:19:49 UTC