W3C home > Mailing lists > Public > www-archive@w3.org > March 2004

Re: Named graphs etc

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Wed, 10 Mar 2004 10:38:05 +0200
Message-Id: <403D8036-726E-11D8-964D-000A95EAFCEA@nokia.com>
Cc: <www-archive@w3.org>, "ext Jeremy Carroll" <jjc@hplb.hpl.hp.com>, <chris@bizer.de>
To: "ext Pat Hayes" <phayes@ihmc.us>


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:32:25 UTC