Re: hashlinks vs trusty URIs

I must admit I did not know about the trusty URIs. Looking at it strictly from the RDF point of view I wonder whether it is a good idea to transform an RDF dataset by modifying the URI-s the way it is done in the example (unless I misunderstand something). Instead, I would think having a separate vocabulary to make statements like

<graph URI> <:hasHash> "hash value" .

etc. seems to be a cleaner approach to me, although it may be a matter of taste. Of course, a clear vocabulary must be defined to describe this (and signatures and other things), akin to what the XML Signature spec does.

I guess this is in line with what Manu & al are exploring and which may (I repeat: may!) become subject of a separate standardization effort @W3C at some point…

If that approach is favoured then, indeed, I do not see a major difference between hashlinks and trusty URIs...

Cheers

Ivan 

> On 6 Jun 2020, at 04:51, Kim Hamilton Duffy <kimhd@mit.edu> wrote:
> 
> I've started evaluating the difference between hashlinks <https://w3c-ccg.github.io/hashlink/> (a CCG/IETF) work item and a similar (but older) effort I recently ran across, referred to as "trusty URIs <https://arxiv.org/pdf/1401.5775.pdf>" (Tobias Kuhn and Michel Dumontier).
> 
> The intent seems to be similar, they are both compatible with ni-URIs, but there may be one compelling difference:
> 
> For trusty URIs, there are two modes: one for byte-level file content and the other that operates on RDF graphs. The relevant text in the hashlinks spec is a little ambiguous in that regard -- I imagine it may similarly enable both modes, but I'm not sure.
> 
> As context, in the EDU space, there is very strong interest in use of linked data <https://docs.google.com/document/d/1pt-VNnjoYgl23Mlu0Tjyax5RgANPBfDijERz0SNYfSo/edit#heading=h.2fde5vhrnfjo>, and I think we are more likely to be interested in operations on RDF graphs, so this isn't just a pedantic exercise. :) 
>  <https://arxiv.org/pdf/1401.5775.pdf>
> Interested in any additional context.
> Thanks,
> Kim
> 
> 
> -- 
> Kim Hamilton Duffy
> Senior Technology Architect
> 
> MIT Open Learning | Digital Credentials Consortium
> 
> kimhd@mit.edu <mailto:kimhd@mit.edu>
> 
> 


----
Ivan Herman, W3C 
Home: http://www.w3.org/People/Ivan/
mobile: +33 6 52 46 00 43
ORCID ID: https://orcid.org/0000-0003-0782-2704