- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Wed, 10 Mar 2004 10:38:05 +0200
- To: "ext Pat Hayes" <phayes@ihmc.us>
- Cc: <www-archive@w3.org>, "ext Jeremy Carroll" <jjc@hplb.hpl.hp.com>, <chris@bizer.de>
On Mar 09, 2004, at 19:12, ext Pat Hayes wrote: > > --DS3241257857011032180 > >> On Mar 08, 2004, at 15:01, ext Jeremy Carroll wrote: >> >>> Patrick: >>>> I still have some questions about how to "bootstrap" trust, such >>>> that >>>> it seems there must be some requirement for each graph to contain >>>> statements reflecting its source/authority (a signature perhaps?) >>>> otherwise, how do you anchor your trust in terms of a given graph? >>>> >>> >>> It seems that there are three issues: >>> >>> - how can an author indicate that a graph is intended to be true (or >>> is >>> intended merely as an example) >> >> My proposal: a specialized vocabulary/semantics for qualifying graphs >> in an authoritative manner by the creator/owner of the graph (probably >> has to include manditory graph signing or the like). > > You can't bootstrap assertion/trust/etc. by putting stuff in graphs. > These are all ABOUT graphs, so for example if you don't trust graphs, > then having them say 'trust me!!' isn't going to make you trust them > more. I would consider the same argument to then be valid against an XML attribute. The point is that it is not the graph saying "trust me", but the creator/owner/publisher of the graph -- presuming there is the machinery to bootstrap a layer of authentication. If you have some statement, the interpretation of which is constrained to the graph in which it occurs (and there are then some issues relating to graph merging that need to be addressed, of course, see below) then that is, I think, functionally equivalent to an XML attribute value expressed in the serialization of the graph. Essentially you are qualifying the graph with statements about the graph which are only relevant for that graph. Now, when it comes to graph merge, the only trick bit I see are occurrences of a "wildcard" term such as x:thisGraph, which would probably have to be mapped to either a blank node, or if the graph is named, to the explicitly defined name of the graph. If the knowledge store keeps track of which statements belong to which graphs (e.g. via quads rather than triples) then one can preserve all bootstrapping information even in a merged graph. E.g. given ex:someQualProperty rdf:type x:GraphQualificationProperty . then the three distinct graphs :G { x:thisGraph ex:someQualProperty #foo } :H { :H ex:someQualProperty #bar } { x:thisGraph ex:someQualProperty #zop } are merged to the set of quads (graph subject predicate object): { :G :G ex:someQualProperty #foo . :H :H ex:someQualProperty #bar . #123 #123 ex:someQualProperty #zop . } etc. and one can then determine, based on the intra-graph semantics of x:GraphQualificationProperty that the graph qualification statements are valid (since one can limit interpretation of the quads to a particular graph). Since the special interpretation of x:GraphQualificationProperty provides the boostrapping machinery needed, additional layers such as those defining trust policies, can then be built atop the graph qualification statements. Patrick -- Patrick Stickler Nokia, Finland patrick.stickler@nokia.com
Received on Wednesday, 10 March 2004 03:53:52 UTC