Re: Adopting the Hashlink spec as a work item?

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

Received on Thursday, 3 January 2019 19:37:03 UTC