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?
melvincarvalhoI guess it's possible to write JSON which is a super set of JSON-LD that's not RDF compliant. And that's probably much harder to do anything useful with in Turtle.
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)
spoggy > <@bjonnh:matrix.org> You can use Robot to transform CSV into RDF using templates (does owl as well)
Grappe is open source & Can Do conversion too https://youtu.be/xDzCk8Xpt3o
bjonnhhave you used it?
bjonnhnot csv but: https://github.com/INCATools/dead_simple_owl_design_patterns
melvincarvalho Mark Hughes (happybeing) (Gitter): just read the article. Lots of confusion about block chains. Everyone has a different definition and different use case. But in reality a block chain is just a chain of blocks. It was originally called the time chain. It's a 1 liner in solid:
Should do the trick.
melvincarvalhoThat'll create a block chain. Which used to be called a Linked List before money got involved.
melvincarvalhoIt's actually a tree, and the consensus rule turns the tree into an ordered chain using a consensus mechanism. In bitcoin that mechanism is longest chain wins, so the chain that proves the most work will be the ordered chain. And it's hard to create a longer chain. Length means amount of work in this case.
melvincarvalhoYou can literally order things any way you want. Just put it in a solid pod is absolutely fine and will solve the double spend problem. Each consensus mechanism has trade offs. The advantage of bitcoin is that it's extremely secure. And that over time builds trust, and creates a reserve currency for the internet. It's actually about building trust via security. You can argue it's over kill, but boot strapping trust is really hard, and takes time. There's no evidence at all that other mechanisms will either build that trust, or offer any other innovation except making the founders lots of tokens.
melvincarvalhoOrdering things on twitter is perfectly fine.
melvincarvalhoBanks order the tx in your statements by running a queue. That's how modern finance works. It's a multi tennant block chain ordered in time. It's just that you have to trust the bank, which many are happy to do. Lots of people are unbanked tho.
melvincarvalhoSo you can solve double spend in solid quite easily, yes. A tally system is a layer above. What that allows is batching between parties who trust each other. They might trust a shared pod for example. That's a nice way to scale an underlying digital system.
melvincarvalhoBut I found more interesting in that article the use of CRDT. These are quite efficient data consensus methods which use neat tricks to keep things in sync. For example if two people are setting a bit, it does not matter in which order they set things when syncing up the different views. This is nice technology for achieving consensus, and lots of ways to do it. Eventually I suspect Solid will use some CRDT to keep pods in sync.
melvincarvalhotl;dr you dont need a lot of electricity to keep a chain of records in a certain order. Lots of ways to do this, the easiest would be sqlite (which you can even use raft with). Or solid. Or twitter. Creating money is a harder problem and has a different trust and reputation profile.