Re: Adopting the Hashlink spec as a work item?

Manu, can you also add this as an issue under so we can track it? (Joe and
I are puzzling over best processes for work items).

https://github.com/w3c-ccg/community/issues

Right now I hope to schedule discussion on this for January 15th W3C
Credentials CG meeting.

-- Christopher Allen

On Thu, Jan 3, 2019 at 11:37 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 1/2/19 11:12 AM, Melvin Carvalho wrote:
> > +1 looks like an interesting initiative
>
> :)
>
> > Wouldn't one way to mitigate this to be to store the context inline?
>
> Yes, but that usually takes lots and lots of bytes (e.g. schema.org).
> We're storing hundreds of millions of JSON-LD documents in our systems
> and storing the context inline is problematic (leads to 2x-50x bloat in
> storage).
>
> > If I was going to implement this suite in solid I'd probably use
> > turtle, which has this advantage.  (I think this work wants to be
> > compatible with turtle, yes?)
>
> Yes, we want to be compatible, but with the warning that you probably
> don't want to inline the context. Hashlink gives you the best of both
> worlds... it's like inlining the context, but you only use a very tiny
> fraction of the bytes doing so.
>
> > Does solving the use case of 3 different places for the context go
> > away, if you put the context inline?
>
> Yes, it does go away... but you make the storage trade-off above (which
> would be cost prohibitive in medium-to-large production systems).
>
> > Or are there other places that hl: can be used?
>
> Hashlink URLs can be used anywhere a regular URL is used *if* your URL
> resolver understands how to resolve hl: URLs. It's a super simple format
> that takes roughly 1 hour to implement a fully conformant Hashlink URL
> processor.
>
> -- manu
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
>
>