Re: Introducing TreeLDR

Thanks for this contribution to the community! It is a hard sell of
understanding for many.

I really like the way of having a place to create your models and generate
the necessary supporting objects from that.
I have some questions

Why is not linkml used more? Ref:
https://linkml.io/linkml/howtos/using-jsonld.html
What will be the main difference between TreeLDR and LinkML? TreeLDR can
produce other objects and use a different language?
Where do all these tools converge? Ories transmute tool, LinkML and TreeLDR?
And where do they diverge?


ᐧ

On Mon, Aug 29, 2022 at 3:47 PM Orie Steele <orie@transmute.industries>
wrote:

> TreeLDR is very cool.
>
> This is the project we currently use in a few places which is similar:
>
>
> https://github.com/transmute-industries/verifiable-data/tree/main/packages/jsonld-schema
>
> It's a collection of tools for working with JSON-LD and JSON Schema.
>
> The primary relevant ones are the ability to:
>
> 1. convert a folder of JSON Schemas (with annotation) to a context.
> 2. convert a JSON LD Document to a JSON Schema.
>
> Another project we looked at briefly is https://linkml.io/
>
> Regards,
>
> OS
>
> On Sat, Aug 27, 2022 at 10:01 AM bengoering@gmail.com <
> bengoering@gmail.com> wrote:
>
>> It would be useful to me to hear a comparison and contrast against other
>> extant langs that (maybe) could be used for this, eg
>> https://en.m.wikipedia.org/wiki/ShEx
>>
>> Always wondering which use case any given prior art could not fulfill.
>> There probably are some, and IMO it’s a gift to posterity to document that.
>> It’s also good marketing about the unique value proposition, if any, about
>> the new thing.
>>
>> Thanks for making this and sharing it Wayne.
>>
>> Sent from my iPhone
>>
>> On Aug 27, 2022, at 7:12 AM, Manu Sporny <msporny@digitalbazaar.com>
>> wrote:
>>
>> On Fri, Aug 26, 2022 at 1:13 PM Wayne Chang <wayne@spruceid.com> wrote:
>>
>> At this stage, we're pre-official release and are looking for feedback to
>> see if it would save anyone else effort
>>
>>
>> Hey Wayne and Timothée, TreeLDR is *really cool*... more below.
>>
>> Hi all, we wrote about our tool called TreeLDR
>>
>>
>> Alright, first up, your organization's ability to have catchy names
>> for software projects continues to impress. TLDR (Too Long, Didn't
>> Read) sums up what we've found most developer's feelings toward the
>> JSON-LD/JSON Schema/Verifiable Credentials/DIDs stack... "I just can't
>> be bothered to read all of this... the customer wants it NOW! Just
>> give me some good tooling so I don't need to learn the equivalent of
>> x86 Assembly for Verifiable Credentials"!
>>
>> makes it easier for developers to work with JSON Schema, JSON-LD, and a
>> variety of other data schema-related languages you need to consider when
>> working with digital credentialing systems.
>>
>>
>> A couple of random thoughts after reading through the blog post:
>>
>> * I wonder if we can use TreeLDR to generate the base JSON Schema for
>> VCs and VPs in the VCWG. It feels like that would be proof that
>> TreeLDR could represent just about any other type of VC one could
>> dream up. I know Orie has done work in this space as well; I don't know
>> how much overlap there is there?
>>
>> * A TreeLDR playground might be useful, just as a syntax checker/live
>> editor, etc.
>>
>> * We've experienced that some people have a religious hatred for
>> namespaces, and others don't... the first population tends to be VERY
>> noisy when they complain, and tend to derail important conversations
>> around the real benefits of such an approach. More on this below:
>>
>> During the development of JSON-LD (~2008 timeframe), we introduced the
>> concept of CURIEs (Compact URI Expressions)... which was something
>> that existed in XML and XHTML2, which enable you to define a namespace
>> and alias it, and then use it in other expressions. For example:
>> vc:credentialSubject
>>
>> Using namespaces exposes you to a group of developers from the late
>> 90s and early 2000s that continue to carry trauma from that time
>> related to "how difficult namespaces were to manage". That vocal
>> minority will fight you every step of the way and tends to derail many
>> conversations. This is why many of the JSON-LD examples these days,
>> and newer contexts don't use CURIEs at all:
>>
>> https://github.com/w3c/vc-data-model/blob/main/contexts/credentials/v2
>>
>> Now, I personally don't have any issue with the use of CURIEs or
>> namespaces... all modern programming languages utilize namespaces to
>> manage subsystem complexity. That said, these "XML namespace haters"
>> can create great friction when it comes time for moving these sorts of
>> things through large enterprises, with Enterprise architects from the
>> late 90s, that have decided that XML namespaces (and colons) are the
>> devil.
>>
>> All that to say, try to consider ways of eliminating or hiding the use
>> of namespaces. For example, instead of "vc:credentialSubject",
>> consider "vc.credentialSubject". Yes, absolutely ridiculous, changing
>> ":" to "." -- they're the same thing... but for some reason, people
>> don't respond as negatively to namespace dot-notation as they do to
>> namespace colon-notation. Apes are funny that way.
>>
>> Just some off-the-cuff remarks, hope they're helpful.
>>
>> Finally, thank you for investing Spruce's resources on new
>> technologies and community tooling. It creates a rising tide that
>> lifts us all.
>>
>> -- manu
>>
>> --
>> Manu Sporny - https://www.linkedin.com/in/manusporny/
>> Founder/CEO - Digital Bazaar, Inc.
>> News: Digital Bazaar Announces New Case Studies (2021)
>> https://www.digitalbazaar.com/
>>
>>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>


-- 

*Snorre Lothar von Gohren Edwin*
Co-Founder & CTO, Diwala
+47 411 611 94
www.diwala.io
<http://www.diwala.io/>
*Stay on top of Diwala news on social media! **Facebook
<https://www.facebook.com/diwalaorg>** / **LinkedIn
<https://www.linkedin.com/company/diwala>** / **Instagram
<https://www.instagram.com/diwala_/>** / **Twitter
<https://twitter.com/Diwala>*