W3C home > Mailing lists > Public > public-rdf-wg@w3.org > January 2012

Re: Thinking on Endorsement use case

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Wed, 18 Jan 2012 10:58:37 +0000
Message-ID: <4F16A5DD.6090803@epimorphics.com>
To: public-rdf-wg@w3.org

On 17/01/12 21:38, Gavin Carothers wrote:
> Also on Wiki at
> http://www.w3.org/2011/rdf-wg/wiki/Example_of_Endorsement_Use_Case
>
> ## Endorsement (3rd Use Case from Sandro)
>
> A system wants to convey to another system in RDF that some person
> agrees with or disagrees with certain RDF triples.
>
> ## Concrete Example
>
> Alice wants to say that she agrees that Bob is named Bob.
>
> Bob has stated in a foaf record that he is named Bob. He did so in a
> Turtle document he hosts on http://example.org/bob/foaf.ttl
>
> 	@prefix foaf:<http://xmlns.com/foaf/0.1/>  .
>
> 	<#me>  foaf:name "Bob",
> 	    foaf:homepage<http://mytotallyfakesite.com>  .
>
> Alice Requests the Turtle document. After reading it she decides that
> she wants to agree with Bob's name, but doesn't with to endorse the
> totally fake site as Bob's homepage.
>
> In order to use any sort of HMAC or other signing system Alice will
> need to produce a byte stream for the message. An example byte stream:
>
> 	0000000 3c 68 74 74 70 3a 2f 2f 65 78 61 6d 70 6c 65 2e
> 	0000010 6f 72 67 2f 62 6f 62 2f 66 6f 61 66 2e 74 74 6c
> 	0000020 23 6d 65 3e 20 3c 68 74 74 70 3a 2f 2f 78 6d 6c
> 	0000030 6e 73 2e 63 6f 6d 2f 66 6f 61 66 2f 30 2e 31 2f
         0000040 6e 61 6d 65 3e 20 22 42 6f 62 22 2e
:-)

>
> Or in ASCII:
>
> 	<http://example.org/bob/foaf.ttl#me>  <http://xmlns.com/foaf/0.1/name>  "Bob".
>
> Once Alice has the byte stream she uses it to compute a hash
> 64487b3448548b7c8a5cfaeb0147bf54. She also creates a full signature
> using her private key. She then writes this all down in a new TriG
> document:
>
> 	@prefix foaf:<http://xmlns.com/foaf/0.1/>  .
> 	@prefix foo:<http://example.org/foo/>
>
> 	@base<http://example.org/alice>  .
>
> 	{<#me>  foo:endorces urn:md5:64487b3448548b7c8a5cfaeb0147bf54;
> 		    foo:signature "SomeSigningBytes";
> 		    .
> 	}
>
> 	@base<http://example.org/bob/foaf.ttl>  .
>
> 	urn:md5:64487b3448548b7c8a5cfaeb0147bf54 {
> 		<#me>  foaf:name "Bob" .
> 	}
>
> Alice then sends the document to Charlie. Charlie is able to take the
> triples in the graph statement labeled
> urn:md5:64487b3448548b7c8a5cfaeb0147bf54 produce the same byte stream
> and verify both the hash and Alice's signature.
>
> ## Results
>
> I am unaware of any use case around endorsement or authority that
> would not require some level of cryptographic signing. Once going down
> that road it's easy to use the byte stream required by ANY HMAC system
> to name the set of triples. This sort of use of IRIs containing hashes
> for identity of arbitrary data is already in wide use today.
> http://en.wikipedia.org/wiki/Magnet_URI_scheme#URN.2C_containing_hash_.28xt.29
>
> --Gavin

Interesting and nice example.

So if as soon as signing and hashing are always going to be involved, 
and that needs to be a concrete array of bytes and so syntax matters, 
then that brings us to the point that its the representation that 
matters (the g-text) not the RDF graph in the abstract (g-snap).   (This 
was Jeremy's point, or what I took from it anyway.)

Do any use cases *require* graph naming, or can they, maybe less 
conveniently, always be solved with identifying a notional 
representation (document, graph serialization) obtained from a place 
(graph container/g-box) at a point time (i.e. an observation).

	Andy
Received on Wednesday, 18 January 2012 10:59:05 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:47 GMT