Model Digest Algorithm

The idea of a signature for a model is an excellent one, but I wonder if the
algorithm needs more work.

As I understand the digest proposal, the digest of a model is the xor of the
digests of the component statements and the digest of a statement is for
some x,y and z:

	Rx(subject_digest) ^ Ry(predicate_digest) ^ Rz(object_digest)

where Rx means rotate x bits and ^ means xor, .

Consider a model with two statements:

	[subject, predicate1, object1]
      [subject, predicate2, object2]

The digest for this model would be:

	  Rx(subject_digest)
	^ Ry(predicate1_digest)
      ^ Rz(object1_digest)
      ^ Rx(subject_digest)
      ^ Ry(predicate2_digest)
      ^ Rz(object2_digest)

The two Rx(subject_digest) cancel out and the resulting signature is
independent of the
subject in the model.

Brian McBride
HPLabs

>-----Original Message-----
>From: Sergey Melnik [mailto:melnik@db.stanford.edu]
>Sent: Thursday, April 27, 2000 21:36
>To: Graham Klyne
>Cc: www-rdf-interest@w3.org; CC/PP WG list
>Subject: Re: CC/PP, RDF and trust issues
>
>
>Graham,
>
>there have been some discussion relevant to building a Web of Trust on
>this list, in particularly with respect to signing RDF *content*. It
>seems important to me that the algorithms for signing RDF 
>operate on the
>RDF model rather than using a particular serialization syntax like the
>current XML-based one. Especially, if the syntax evolves over time.
>
>You can find a summary of some ideas of how that can be done at
>
>	http://nestroy.wi-inf.uni-essen.de/rdf/sum_rdf_api/
>
>The above description of the algorithm is based on the working code
>downloadable from
>
>	http://www-db.stanford.edu/~melnik/rdf/api.html
>
>In this approach, a cryptographic digest of a statement or a 
>whole model
>is taken to be the ID of the corresponding statement or model. Thus,
>reification comes "for free", i.e. one can make assertions about models
>directly by using their digest-based IDs.
>
>I believe that RDF is a great way of establishing trust on the Web and
>you are on the right path. I'm looking forward to hearing more about
>your efforts!
>
>Sergey
>
>
>Graham Klyne wrote:
>>
>> [...]
>>
>> In private discussions, a model has emerged in which an "assurance"
>> property can be applied to a reification of the RDF statements, whose
>> object is [an identifier of] the principal who signed the 
>original expression.
>>
>> [...]
>>
>> It seems that the shift from "signature" to "assurance" parallels the
>> distinction between the serialization of an RDF graph, and 
>the abstract
>> graph itself.  A signature, by its nature, applies to the 
>serialized form,
>> not the graph, but it does confer information that is 
>meaningful as part of
>> the knowledge potentially represented by the graph.
>>
>> [...]
>>
>> Implicit in this question is the idea that dealing directly with
>> reification in the CC/PP model will create a significant 
>barrier to its
>> adoption.  The CC/PP requirements document has already attracted some
>> public comment that it is over-complex;  irrespective of whether such
>> comments are justified, they send a signal that employing the full
>> expressive power of RDF will likely be problematic.
>>
>> [...]
>>
>> (c) if such an approach is to be adopted, or indeed any 
>other approach, it
>> may be that this is something that is going to be a common 
>requirement for
>> all sorts of RDF applications.  Therefore, it seems 
>appropriate that it is
>> defined as a common RDF facility rather than something that 
>is specific to
>> CC/PP.  Has any substantial work in this area already 
>tackled by the RDF
>> community?
>>
>> [...]
>>
>> Given that CC/PP is committed to be built upon RDF, it seems 
>desirable to
>> engage as much RDF expertise as we can in the CC/PP design.  It is
>> important for us to find a design for CC/PP that is direct 
>and intuitive
>> for developers and users, and that also does not violate the 
>RDF model or
>> common usage.  One area where this seems to be particularly 
>important is
>> that the trust issues are resolved cleanly and carefully.
>

Received on Friday, 28 April 2000 12:41:46 UTC