- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Thu, 11 Mar 2004 11:45:14 +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 10, 2004, at 19:00, ext Pat Hayes wrote: >>> 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. > > No, because XML attributes aren't required to have truth-functional > semantics, as RDF is. They can 'mean' anything. See my recent discussion about a distinct "bootstrapping interpretation" phase prior to a full RDF interpretation. I look at this bootstrapping phase as analogous to processing of XML attributes prior to full RDF interpretation, but using statements. If the boostrapping interpretation phase succeeds, then those bootstrapping statements should still be true and valid for the full RDF interpretation. > >> >> 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. > > But the whole RDF design is predicated on the possibility of triples > being freely transmittable, mergeable with other graphs, etc. etc. So > what happens to the triple "I assert foo" when it gets imported from > my graph into your graph? It no longer refers to the owner of THAT > graph. I think we need to require explicit graph naming, possibly even using URIs, to deal with issues of merging. If some bootstrapping statement has a particular graph as its subject, then if that graph is merged into another graph, (a) the statement will no longer be relevant for bootstrapping of the new graph since its subject won't be the same as the new graph, and (b) if the resultant graph is deemed to be asserted and trustworthy by the agent, then the statement should in any case remain valid insofar as its qualification of the earlier merged graph. The bootstrapping tests are done at points of entry into an agent's knowledge base. If the bootstrapping succeeds, then they are later innocuous if merged into some other graph. Yet if the agent has a knowledge base that preserves graph membership of statements (quads, quintuples, whatever) then specialized trust machinery can continue to use those statements to filter its views of what is or is not relevant to a particular application. I agree, though, that having any kind of wildcard such as x:thisGraph would add alot of difficulties without direct modification to the presently defined RDF merge operation and probably is best avoided. > > If we are going to put the 'asserting' into the RDF itself, then we > need a way to refer to the asserter that is reliably preserved when > triples (not just whole graphs) are transmitted across the Web. Seems > like we need to use URIs. Perhaps. I'd think, though, that blank nodes should also suffice. The key is that the identity of each graph remains distinct no matter how many merges/extractions occur. That *should* be the case for blank nodes, yes? > >> 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. > > Which breaks the Web architecture assumed for RDF, seems to me. Not at all. See below. > Graphs are only abstractions, and sets of triples can be merged or cut > up at will by applications. Yes, but if a particular graph is modified in any way, it is no longer the same graph and any new graph should have an identity distinct from the original graph and thus any statements qualifying the original graph are irrelevant for any other graph and thus are innocuous if included in a new graph and represent no loss of information if omitted from the new graph. If some agent syndicates knowledge from multiple graphs, it will perhaps test the assertiveness and authenticity/trust of those input graphs, do its modifications, and when passing along a new graph to some other agent, will qualify that *new* graph per it's own identity/credentials. So if graph :X has a statement :X trix:asserted "true"^^xsd:boolean . and that statement is merged into graph :Y, so what. An agent determining the assertiveness of :X will not be looking at graph :Y. And an agent determining the assertiveness of graph :Y will disregard statements about other graphs. Thus, the inclusion of the statement in graph :Y is innocuous. The semantics of the trix: vocabulary will make it quite clear that agents should not believe/trust any statements made about a graph which occur in another graph. And agents won't be able to effectively employ trust machinery without, I think, additional support for maintaining graph membership, so less capable (i.e. "vanilla") RDF/OWL applications won't be able to make anything of those statements anyway unless working exclusively on a graph by graph basis. Agents who are savvy about the bootstrapping vocabulary may even choose to filter out such statements when doing graph merging, knowing that they are irrelevant to any graph but that within which they were originally asserted. > >> 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. > > Sure, but what about pieces of named graphs? What if I take a named > graph, toss out half the triples, then merge the rest with a piece of > another named graph? Then you have an entirely *different* graph, and any statements about the other graphs are irrelevant to the new graph, and thus innocuous. It's a simple as that. Cheers, Patrick -- Patrick Stickler Nokia, Finland patrick.stickler@nokia.com
Received on Thursday, 11 March 2004 04:45:22 UTC