spoggyIwan Aucamp (Gitter): could this felt your need https://scenaristeur.github.io/spoggy-simple/js-xlsx/
melvincarvalhoMark Hughes (happybeing) (Gitter): JSON-LD is a tricky one. It was designed to do one of two things. Either extract RDF from JSON. Or be a serialization for RDF in JSON. In the end the spec went with the latter. 1.0 was a reasonably good approximation. But lacked relative URIs. That's largely fixed in 1.1 Is there anything you dont like about JSON-LD?
melvincarvalhoI think 1.1. is quite good in terms or RDF. Happy to hear thoughts otherwise. What would have been REALLY nice is if JSON had had a native way to serialize a URI e.g. with angle brackets <URI> like we use in Turtle. I believe that was discussed too. But it's not native and would require transpiling. And transpiling is a pain. Would have made life a lot easier tho if that was native in JSON. In another universe maybe!
melvincarvalhoMy feeling is that there's quite a large proliferation of JSON-LD now in 2020. e.g. the fediverse. Used on many millions of web pages for SEO in data islands. More than in the past, anyway. Turtle still very popular in LOD.
melvincarvalhothis is the czech covid 19 data API
melvincarvalhothe CSV Schema actually is JSON-LD or looks like it
melvincarvalhoMark Hughes (happybeing) (Gitter): turtle was designed for readability and for thinking in graphs. I really like it for that reason. It also has some nice properties such as allowing comments, and not needing a async lookup. The advantage that JSON-LD has over Turtle is that it has a native parser. JSON-LD is supposed to be RDF compliant. There was a lot of work to ensure that in the spec. Have you come across anything that isnt compliant?
melvincarvalhoreally interesting post that contributed to the birth of JSON-LD almost 10 years ago
melvincarvalhoduring the standardization process, it was a requirement to be compatible with RDF
melvincarvalho > One is to create a JSON serialization of RDF, capable of serializing all
the RDF concepts (anything Turtle will be able to), an optimized machine
to machine RDF transportation format. Most languages support JSON
parsing now, and that parsing is very quick compared to XML and formats
which require a custom parser (like turtle). Personally I see this as an
easy hit, feel it would be well worth doing, and to be totally
The second need is much more complex, to create a JSON format which
allows people to publish and work with linked/web data easily.
melvincarvalhoI find that really interesting.
melvincarvalhoJSON-LD as it is today addresses the first part
melvincarvalhoI also find that 2nd part really interesting, given the growing proliferation of JSON as of today and the network effects around that
melvincarvalhoStill not 100% solved
melvincarvalhoJSON-LD doesnt work very well in solid right now. But IMHO given the network effect that has grown up around it, it's worth supporting.
melvincarvalhothis was linked from the data set I noted above
melvincarvalho> The CSV on the Web Working Group was chartered to produce a recommendation "Access methods for CSV Metadata" as well as recommendations for "Metadata vocabulary for CSV data" and "Mapping mechanism to transforming CSV into various formats (e.g., RDF, JSON, or XML)". This document attempts to partially satisfy the "Metadata vocabulary for CSV data" recommendation by definin all terms used in [tabular-metadata].
melvincarvalhoIwan Aucamp (Gitter): might be helpful ^^
bjonnh(templates are included in CSV)