Re: Named graphs etc

On Mar 10, 2004, at 18:09, ext Pat Hayes wrote:

>
>> Mindful of time pressure ...
>
> OK, but...
>
>> I suggest the following approach for our paper ...
>>
>> 1) introduce a property
>>    rdfx:assertedBy
>>
>> whose domain is graphs and range is agents union documents.
>
> It seems to me that no such approach can possibly fly.
>
> The task is how to get graphs asserted. Asserted means that you are 
> supposed to accept the truth of the statements in it, if you believe 
> the asserter. If a graph is not asserted, in particular, you are not 
> supposed to take it being true or making any claims: its just a graph 
> for you to contemplate. It doesnt even have statements in it, just 
> formulae: they only get to be statements when they are asserted. An 
> unasserted graph is just wallpaper. So now, if asserting a graph is 
> done by making a statement in a graph, how do ANY graphs EVER get 
> asserted? Triples with that property in them can occur in a graph out 
> the wazoo, but unless the graphs containing those triples get 
> asserted, there's no reason to think that they are saying anything 
> about anything: they are just there for you to contemplate. So they 
> don't cause any asserting to be done.  There HAS to be something 
> OUTSIDE the graph which indicates that the graph is being asserted, 
> before there is any reason the accept the truth of any graph at all.

Right. My own suggestion was that there would be a special predicate
which has, to a minimal degree, a special extra-RDF interpretation such
that, if the graph contains a triple having that predicate, and the 
object
of the triple is the value 'true', and the subject of the triple 
corresponds
to the graph containing the triple, then the graph is treated as 
asserted.

I.e., there is a process by which a graph is determined to be asserted 
or
not, and a step in that process is to presume that the graph is asserted
(thus, we have statements) and examine the statements in the graph to
see if any statements using the bootstrapping vocabulary re-affirm that
the graph is actually asserted. If not, then the process ends by 
concluding
that the graph is not asserted -- insofar as the RDF MT is concerned.

Thus, the decision about assertion is performed in a sort of virtual 
ante-chamber
leading into the RDF domain. If it passes all the criteria for 
assertion, it
moves into the RDF world. Else, it is excluded.

>
> Having the graph refer to itself is no help: it you arent inclined to 
> take it as being asserted, what it says about itself has no influence 
> on you. If you are so inclined, then having it say its asserted is 
> redundant.

The point is that, for the basis of bootstrapping, you interpret the 
graph in
isolation, as if it is asserted, and only if the bootstrapping tests 
succeed
do you treat it as asserted for general processing governed by the RDF 
MT.

>
>>
>> 2) include examples in which a PKI signature of such a statement is 
>> included in which the asserting agent signs the statement of 
>> assertion
>>
>> 3) include text that describes the bootstrapping problem and note 
>> that the example provides one mechanism for bootstrapping trust, but 
>> noting that the HTML web largely works, providing adequately trusted 
>> information, without widespread use of such mechanisms
>
> I'm not talking about bootstrapping trust, but bootstrapping 
> assertions.

These are two issues which, IMO, both require an intra-graph 
bootstrapping
mechanism. One has to do with the graph "asserting itself" so to speak. 
The
other has to do with identity of and authentication of the 
source/authority
of the graph. Both, IMO, must be specified in terms of the graph 
itself, and
should not be definable by statements in other graphs.

> If publication is not assertion then right now, NOTHING is asserted in 
> any RDF anywhere. How do we get this whole RDF Web off the ground?

If there is no explicit statement that a graph is or is not asserted, 
then
for legacy reasons, agents may decide to presume that it is asserted. 
That
gets the SW off the ground given the presently published graphs.

If there is an explicit statement that a graph is not asserted, then the
graph constitutes a quotation (but one which is in a form more suitable
for reasoning per a hypothetical scenario).

If there is an explicit statement that a graph is asserted, then the 
graph
is asserted, *and* there is a solid basis for accountability (and 
trust).

Most B2B applications will, I expect, require explicit statements about
the assertiveness, authority, and other qualities of a graph.

>
>>
>> We might also want an rdfx:notAssertedBy property for explicitly 
>> stating that a graph is fictional, in the eyes of its author (or 
>> anyone else).

Taking into account one of Jeremy's proposed two properties, I think
a reasonable, minimal vocabulary/model might be as follows:

    trix:Graph
       a rdfs:Class ;
       rdfs:description "An RDF Graph." .

    trix:GraphQualificationProperty
       a rdfs:Class ;
       rdfs:subClassOf rdfs:Property ;
       rdfs:description "The class of properties which qualify the graph 
in which the statement occurs." .

    trix:Authority
       a rdfs:Class ;
       rdfs:description "An authority, or source, of RDF assertions." .

    trix:asserted
       a trix:GraphQualificationProperty ;
       rdfs:description "Used to specify if a graph is asserted or 
unasserted." ;
       owl:maxCardinality "1"^^xsd:nonNegativeInteger ;
       rdfs:domain trix:Graph ;
       rdfs:range xsd:boolean .

    trix:assertedBy
       a trix:GraphQualificationProperty ;
       rdfs:description "Used to specify the authority asserting a 
particular graph." ;
       owl:maxCardinality "1"^^xsd:nonNegativeInteger ;
       rdfs:domain trix:Graph ;
       rdfs:range trix:Authority .

    trix:signature
       a trix:GraphQualificationProperty ;
       rdfs:description "Signature used to authenticate a particular 
graph." ;
       owl:maxCardinality "1"^^xsd:nonNegativeInteger ;
       rdfs:domain trix:Graph .


(we may even want to specify the above properties as having 
owl:cardinality "1"...
such that if the bootstrapping vocabulary is used at all, the 
"certificate"
is complete)

--

The semantics of trix:GraphQualificationProperty is special, in that 
such
properties only have valid interpretations regarding their graph 
subjects when they
occur in statements contained by the graph indicated by the subject.

Thus, there are now two distinct phases/stages of interpretation:

1. Bootstrapping Interpretation:

Interpret graph in isolation as if it were asserted.

a) Test Assertion

Check for statements with trix:asserted where the subject is the
graph in question.

If the graph is explicitly stated to be unasserted, or if there
are any contradictions between any trix:asserted statements, stop;
the graph is taken to be unasserted.

(some agents may also choose to treat graphs having no explicit
assertion specified as unasserted)

Otherwise, treat graph as asserted and continue.

b) Test Authority/Authentication

Check for statements with trix:assertedBy and trix:signature where
the subject is the graph in question.

If the authority and signature are invalid, stop; the graph is taken
to be untrustworthy.

(some agents may also choose to treat graphs having no explicit
authority and signature specified as untrustworthy)

Otherwise, treat graph as authenticated (ultimate trust possibly further
qualified by additional machinery), and continue.

2. "Normal" RDF/OWL Interpretation:

... business as usual ...

--

Any statements using the bootstrapping vocabulary which were true
for the bootstrapping interpretation should still be true for
normal RDF/OWL interpretation, and as such, can remain an integral
part of the auxilliary trust machinery.

The key to the boostrapping is that first special phase of
interpretation (which is, agreed, not provided for by the RDF MT).

For that initial interpretation, only the bootstrapping statements
are relevant (we may even restrict interpretation to only those
statements having bootstrapping predicates, ignoring all others).

After successful bootstrapping, we can then use "normal" RDF 
vocabularies
to build the necessary additional trust mechanisms, once we know (a) who
supposedly said what, (b) that what was said was trully asserted, and
(c) that the assertions were actually made by the particular authority.

Eh?

Patrick

--

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

Received on Thursday, 11 March 2004 09:44:06 UTC