- From: Chris Bizer <chris@bizer.de>
- Date: Wed, 10 Mar 2004 10:47:06 +0100
- To: "Patrick Stickler" <patrick.stickler@nokia.com>, "ext Pat Hayes" <phayes@ihmc.us>
- Cc: <www-archive@w3.org>, "ext Jeremy Carroll" <jjc@hplb.hpl.hp.com>
Hi, a few comments: On assertion: Pat: >0. Asserting is a relationship between documents (? resources? agents >who publish documents? owners of resources? whatever....) and graphs. I would opt for "a relation between agents and graphs". And avoid bringing documents in. I think there are two layers: 1. A content/speech act layer, where agents claim information. 2. A distribution layer, where their speech acts are distributed via documents or web services or whatever in the future. All the asserting and trusting stuff should take place on the first layer. The distribution layer should (at least theoretically) be transparent to the agents. Maybe it is also helpful in this context to use the statement/stating terminology: 1. RDF Statements don't involve speech acts. So statements are contained in graphs that describe themselves as :G1 x:GraphQualificationProperty x:unasserted or are described somewhere else somehow as unasserted. 2. RDF Stating: Through a speech act a statement becomes a stating. So a stating is the result of an agent claiming a Statement. On trust: Patrick: > > 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. > I think this is the right approach. We should define named graphs in a way that agents can talk about their graphs (asserting or not asserting them or whatever) and the graphs of other agents (agreeing, denying or whatever). This should be done using vocabulary, because we don't know the "whatever" and the users of named graphs might have requirements we didn't think about. Pat: >Alternatively, one can give a URI which >points to another document which acts as a 'publication warrant'; >this might for example record provenance information, give security >key information, things like that. And it can be stored on a secure >server somewhere, safe from harm, and providing a checksum to use as >security against malicious changes to the warranted graph. This is one possibility amongst many. We should now only develop the base machinery. The specific application domain will later determine: - which mechanisms a suitable for an information provider to support information consumers in trusting his content. - which trust mechanisms are suitable for a information consumer in a specific situation to make up his mind if he will trust the information. Chris
Received on Wednesday, 10 March 2004 05:45:18 UTC