Where communities thrive

  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
  • Aug 11 2021 20:52
    @RubenVerborgh banned @mikeadams1
  • Jan 04 2021 20:23
    @RubenVerborgh banned @WebCivics_twitter
  • Jan 04 2021 20:18
    @RubenVerborgh banned @SailingDigital_twitter
  • May 27 2019 06:08
    User @Mitzi-Laszlo unbanned @in1t3r
  • May 23 2019 06:49
    @Mitzi-Laszlo banned @in1t3r
  • May 16 2019 09:49
    @Mitzi-Laszlo banned @mediaprophet
  • Feb 01 2019 22:04
    User @melvincarvalho unbanned @namedgraph_twitter
  • Feb 01 2019 21:49
    @melvincarvalho banned @namedgraph_twitter
melvincarvalho I 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!
melvincarvalho My 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.
melvincarvalho on the topic of rdf, cvs and JSON, I noticed something interesting yeterday
melvincarvalho this is the czech covid 19 data API
Mark Hughes (happybeing/theWebalyst)
Melvin, I don't like looking at JSON-LD is my main objection, added to the point that something in JSON-LD is not necessarily RDF compliant. I don't know if it is good for particular things other than people already having tools for messing with JSON (but I think that's double edged because people will not realised what RDF is about if they drift from JSON to using JSON-LD.
melvincarvalho it has data in JSON, CSV and this other thing called "CSV Schema"
melvincarvalho the CSV Schema actually is JSON-LD or looks like it
melvincarvalho Mark 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?
melvincarvalho I 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.
Mark Hughes (happybeing/theWebalyst)
I read in the JSON-LD spec that it isn't necessarily RDF compliant (I think that's the word used). Turtle is as you say much nicer. JSON is ugly enough, but when I was learning RDF JSON-LD made things really hard to understand. I still haven't understood it because I avoid it :wink:
Today though I'm going to study a bit of Rust for a possible new side project related to SAFE. Rust is ugly in its own way :grinning:. I guess its mostly about getting used to something new, but some things are elegant and clarify things, while others get in the way.
melvincarvalho really interesting post that contributed to the birth of JSON-LD almost 10 years ago
melvincarvalho during 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.

melvincarvalho I find that really interesting.
melvincarvalho JSON-LD as it is today addresses the first part
melvincarvalho I also find that 2nd part really interesting, given the growing proliferation of JSON as of today and the network effects around that
melvincarvalho Still not 100% solved
melvincarvalho JSON-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.
Mark Hughes (happybeing/theWebalyst)
I'm not convinced JSON-LD is a good thing overall. You can do stuff in it, but the JSON tooling isn't built for that, so you if you want to do stuff with RDF you're better off with a library that understands RDF in which case JSON-LD isn't helpful. It's not my area, but that's my impression. I'm a big fan of JS but I don't get JSON-LD.
Off to look for Rust stuff! I've been noticing your 'spux' updates and interested to see what emerges :smile:
Hope all's well.
melvincarvalho Thanks :) Back to CSV in RDF :
melvincarvalho http://www.w3.org/ns/csvw
melvincarvalho this 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].
melvincarvalho Iwan Aucamp (Gitter): might be helpful ^^
bjonnh You can use Robot to transform CSV into RDF using templates (does owl as well)
bjonnh (templates are included in CSV)
bjonnh Template | robot

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



& source https://github.com/assemblee-virtuelle/Semantic-Bus

bjonnh sounds much more complicated to use
bjonnh have you used it?
spoggy No but I know the dev that made me a demo, and it looks really friendly & cool, when you get the start to convert every data flux or file to another. I'll poke the dev to join if you want or you can ask him : @SimonL:matrix.org
Hello, I am Simon, the main developper of Sementic Bus. My english is very bad, sorry. This is an Saas Graph Oriented ETL. Grappe is the commercial deployment by Data Players. It is little more complexe than specific translator but much more flexible. input supported serialisation contains rdf/ttl/owl/json/json-ld/csv.... but output only support json/json-ld/xml/excel/csv. Other output sérialisation requiere somme development hours but it is possible and easy. All kind of transformation can be done betwen input and output.
By exemple this flow translate form result csv into LDP server (semapps base on fuseky)
slug of uri generated for each 5 type of subject considering unicity from data in column of csv
Mark Hughes (happybeing/theWebalyst)
@melvincarvalho hey, have you read about AT2 (an innovative concensus mechanism that avoids the pitfalls of Blockchain)? Reading the following article reminded me of your tally system, and I wonder if the two would work on Solid. See 'Crypto-Twitter' half way down, although the whole article is very good: https://www.computing.co.uk/feature/4017118/at2-answer-cryptocurrency-energy-performance

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:

<> <#blockchain> ( <#1>, <#2>, <#3> ) .

Should do the trick.

melvincarvalho That'll create a block chain. Which used to be called a Linked List before money got involved.
melvincarvalho It'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.
melvincarvalho You 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.
melvincarvalho Ordering things on twitter is perfectly fine.
melvincarvalho Banks 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.
melvincarvalho So 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.
melvincarvalho But 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.