2 ms·
As an ontology enthusiast, it saddens me to see that ATProto went for their own data model ([link:Lexicon]) instead of using the standard JSON-LD (I wonder if t
by Diti 2y ago
As an ontology enthusiast, it saddens me to see that ATProto went for their own data model ([link:Lexicon]) instead of using the standard JSON-LD (I wonder if they considered Turtle – which is streamable, unlike JSON).
I get why they did that (graph data is, uh, particular to work with, especially for newcomers who only know JSON), but ATProto not using JSON-LD is actually what made me unwilling to tinker with the protocol.
Not a direct answer to your question, sorry. Mostly a rant.
[link:Lexicon]: https://atproto.com/guides/faq#why-create-lexicon-instead-of-using-json-ld-or-rdf https://atproto.com/guides/faq#why-create-lexicon-instead-of...
- str4d 2y agoThere are a few more details about the reason they didn't use JSON-LD in Paul's blog post [0]. [0]: https://www.pfrazee.com/blog/why-not-rdf https://www.pfrazee.com/blog/why-not-rdf
- apitman 2y agoI'm sorry but JSON-LD is a massive pain to work with in statically typed languages. Certainly is in Go at least. The flexibility is the problem, ie you never know if something is going to be an object or an IRI (did we really need a 3rd name for URIs?) to an object. I think you could get most of the benefit while still requiring specific types.
- Diti 2y agoYou shouldn’t be having this problem if you use a library which offers normalization (like github.com:piprate/json-gold) so that you get objects when there’s an IRI context, and a simple string when there’s a regular IRI.
- apitman 2y agoI'm not aware of any such libary for Go. Besides, I prefer protocols that are simple enough to implement myself. That's not feasible in every case, but it certainly is for the social media use case.