Re: Named graphs etc

On Mar 10, 2004, at 11:47, ext Chris Bizer wrote:

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

I agree with this distinction. What matters here is the graph and how
the graph is qualified, not how the graph is serialized and passed 
around
(though one might optionally use external machinery for validating
graph qualifications such as authority, signatures, etc.)

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

Right.

> 2. RDF Stating: Through a speech act a statement becomes a stating. So 
> a
> stating is the result of an agent claiming a Statement.

Not sure I follow this. Can you provide an example?

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

Exactly. If we can get the semantics of that key bootstrapping class
of properties (e.g. x:GraphQualificationProperty) nailed down, then
we have a fully extensible mechanism for grounding all kinds of higher
layers such as those relating to trust, authentication, 
contextualization,
relevance, etc.

The vocabulary approach is thus both backwards compatible with the
latest specs, since we don't force any change to the RDF/XML 
serialization,
and future compatable with new, unknown layers requiring hooks to
the graph itself.

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

Agreed. And I really, really like the idea of the 'publication warrant'.
It seems to me that that would be a good way to provide "semantic web
certificates" for graphs exchanged between federated agents.

Cheers,

Patrick

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Wednesday, 10 March 2004 06:01:13 UTC