- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Wed, 10 Mar 2004 11:14:35 +0200
- To: "ext Pat Hayes" <phayes@ihmc.us>
- Cc: "ext Chris Bizer" <chris@bizer.de>, <www-archive@w3.org>, "ext Jeremy Carroll" <jjc@hplb.hpl.hp.com>
On Mar 09, 2004, at 23:13, ext Pat Hayes wrote: >> >> One thought that occurred to me is that it might be cleaner/better to >> bootstrap the trust architecture using a specialized vocabulary which >> applies *only* to the graph in which statements using that vocabulary >> occur. > > that is essentially a 'this graph' naming function, right? "This graph > asserts..." Correct. > >> >> This could also serve to allow folks to specify whether a graph is >> asserted or not. > > I'm coming to think that we need to provide for separating out a graph > from its assertion. Example: A publishes and asserts a graph, but B > wants to refer to it without (re) asserting it (maybe B wants to argue > with it). So B must be able to refer to the graph and its content > without referring to the assertion of the graph. So there has to be a > conceptual distinction between the published (named) graph and its > assertion. > > (Quick side question: do named graphs allow one to publish a reference > to a graph without publishing the graph (never mind about asserting)? > that is, can I say " a graph called "ex:myprivategraph" exists but I'm > not going to show it to anyone" ??) I don't see why not. People frequently refer to their private parts and make claims about them without whipping them out in public ;-) > > Back to main thread. But unless we prove for some kind of > publish-as-assertion, we can't get off the ground. So, suggestion > (putting together various ideas, including Patrick's below): > > 0. Asserting is a relationship between documents (? resources? agents > who publish documents? owners of resources? whatever....) and graphs. > > 1. Primitive asserting is done by (publishing) a document with an > asserting tag. and which which contains a(n instance of a) graph. > That document asserts that graph. You need an asserting tag to get > the whole process started, so asserting isn't something that can > happen by accident. Right. Though (a) I think/hope that a specialized vocabulary could be used in the graph instead of in the serialization (b) I'd like to see the machinery generalized to graph qualification of any kind, including assertion, authentication/signing, scope/context, precision, etc. > 2. But, in addition, one asserted graph can assert another graph, by > reference using the name. In this case the asserter of the first graph > asserts the named graph. I don't buy this. Allowing one graph to assert another allows one person to modify the intended purpose of someone elses graph. If I publish a graph but do not assert it. Nobody should be able to publish another graph having a statement asserting my graph. This is why I limit the interpretation of that special boostrapping vocabulary, members of x:GraphQualificationProperty, to the graph in whch they occur. The x:thisGraph term may prove too troublesome, and we may have to require explicit graph naming and explicit use of graph names, but still, qualification of a graph should be limited to the graph (or document by which the graph is published) and not allow "infection" from other graphs. This should be a fundamental principle of the boostrapping machinery: all graphs stand alone insofar as their qualifications are concerned. > So I can assert something that is published and named, even if the > thing I'm asserting wasn't asserted by its own publication. Someone > else can deny it, maybe, and someone else can say something about it > without taking any particular stance towards asserting or denying it. > The graph expressing the content is just sitting there being referred > to. Nope. Don't like it. > > Note, if A asserts B and B asserts C, A does not necessarily assert C. > Assertion is only done explicitly, not by transitive closure. Eh? So, if I'm reasoning over some set of graphs A, B, and C, I have to keep track not only of whether A, B, or C are asserted but *how* they are asserted, and perhaps one conclusion follows per statements in A but don't follow per identical statements in C because of where/how each graph was asserted? Yikes! I think it would be far simpler, and more than sufficient, to allow the authority of each graph to specify whether a given graph is or is not asserted, and then build trust "filters" based on top of that foundation. > On the other hand, if B says that A asserts C, and A asserts B, then A > asserts C; that is, assertion *by A* is transitive. Also, if A > asserts B and B imports C, then A has asserted C. > > 3. A graph can do both things at once, if it wants to. That is, it can > be asserted with a tag, and it can say of itself that it is asserted. > This is a very unambiguous way to assert yourself. Why couldn't it simply say of itself that it is asserted, and we can do away with the need for the tag/attribute entirely? > > It can also, BTW, say of itself that it does not assert itself, which > is odd but not paradoxical, since asserting isn't transitive (unlike > importing). Even if A does not assert itself, B can assert it; and > this can make sense even if A and B are the same asserter (eg owned by > the same owner doing the assertion. I still don't like external assertion. True, a given agent can pretend that a graph is asserted, regardless of what the owner of the graph says, but that is different from actually affecting the assertiveness of a graph in general by agents syndicating numerous graphs and not realizing that one graph asserts another graph, which otherwise would be disregarded by the agent as unasserted... I think here be lots of dragons... > > The only contradictory case is a graph *tagged as asserted* which says > explicitly that it does not assert itself. And in this case we could > just say that this is an assertion of a contradiction, and assertions > of contradictions are content-free. Note this is not a logical (= > RDF-semantic) contradiction, since the crucial asserting tag isn't > visible from within the RDF itself. Yet if we simply do away with the tag/attribute, then such contradictions would not occur. > > 4. An assertion can be done by a pair of graphs, A which expresses the > content (and is not asserted) and B which asserts A and is asserted, > as in 2. above. But also, this can be modified/extended so that A tags > B as its warrant, providing a kind of secure external assertion, a > warranted handshake. Note that since each refers to the other, the > warrant can only be used once in this case. But if you only first had graph A, which is unasserted, then you could not IMO rightly interpret the statements of A to get the reference to its warrant graph B, which then asserts A. I like the idea of warrants, as a means of stronger authentication/validation, but not as a mechanism for assertion. > > --- > > All of these cases provide for a separation of content from assertion, > since A can refer to B by name without being understood to re-assert > B; this allows A to express doubt about another assertion, say. (If A > wants to re-assert B, it can do so explicitly.) > > I think this provides for most of what anyone could want. And a good bit of what we might not want ;-) > It can take existing usage and fix it up without changing any graphs > (other maybe than to give them names: we can use their URLs for now > :-) Yes, but it requires changes to RDF/XML, which is probably far more costly than most other approaches -- in terms of process/politics/acceptance rather than actual technical effort. >> >> Thus, the name of the graph is used in statements within that graph, >> and >> statements using a special property, e.g. x:isAsserted would >> only be interpretable if the subject of the statement is the >> same graph containing that statement. > > No, let it work for any pair. Then B can assert A even if A doesn't > assert itself. Which makes perfect sense. It makes sense, but I think creates far more problems then it solves, per my comments above. Patrick -- Patrick Stickler Nokia, Finland patrick.stickler@nokia.com
Received on Wednesday, 10 March 2004 05:06:53 UTC