Re: Named graphs etc

>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.

No, because XML attributes aren't required to have truth-functional 
semantics, as RDF is. They can 'mean' anything.

>
>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.

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.

>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. 
Graphs are only abstractions, and sets of triples can be merged or 
cut up at will by applications.

>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?

Pat

>  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


-- 
---------------------------------------------------------------------
IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes

Received on Wednesday, 10 March 2004 12:00:09 UTC