Re: Thinking on Endorsement use case

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 UTC