Is RDF "hard"?

[dynamoRando]

Long post ahead.

Wow, there’s a lot here to unpack. I want to be mindful that I’m not sucking the oxygen out of the thread, but there’s some tangential thoughts that I have as well overall. I’m also going to do a little bit of self promotion as well.

Topics

Item Number	Item
1	Developing With RDF
2	Solid Project Execution / Dev Experience
3	What problem are we trying to solve?

I’m going to skip the first item for a moment and come back to it.

Solid Project Execution

In response to @aschrijver:

@aschrijver

Some personal impressions, that may be wrong… To me it seems like there are 2 tracks to the Solid project that are intertwined:

1. The practical path . Defining ways to have secure personal data vaults that are decoupled from their application, and where the linked data in them increases the potential for semantic interoperability (lowers the barrier to reuse). Comprehensive, mostly existing standards suffice.

2. The Big Vision . Broadscale, seamless interoperability with ease. Building on 1) with many additional specs and layers of complexity, but abstracted away by a rich and mature ecosystem. A rebooting of the Semantic Web.

I mentioned this in my introduce yourself post, but I’m coming back to the Solid project after reading about it a few years back.

A few years ago, I could see that the Solid project was just getting off the ground, and as I poked around, didn’t see initially a whole lot that I was wanting before jumping in (more in a second); so I figured I’d give it a year or two as the project matured. As mentioned previously, I was kind of expecting more DevRel.

I’m going to skip defining what DevRel is; but having been used to that experience with big tech companies (Microsoft, Apple, Google) - I’ve been spoiled with an abundance of:

• Docs
• Video walk-throughs
• Social media exposure

Since I’ve been mostly exposed to Microsoft technologies, I’ll refer to what I’m familiar with when getting booted with any new technology that Microsft introduces (or takes over )

If I need …

• To figure out how to use a feature, I can almost always find both a technical walkthrough as well as an architectural one on Microsoft Docs. This is going to sound dumb, but I the documentation. It’s really good in my view.
• To understand a general walkthrough, I can almost always find a corresponding YouTube video, either by the community or by MS employees (example 1 and 2) that walks me through technology item X.
• To ask questions: there’s almost always a Discord server I can hop into to ask questions; and/or there’s usually MS people on Twitter that I can tweet at and usually get a response. Or alternatively, Stack Overflow.

The point is: there’s a lot of channels to flatten the learning curve.

Now, I understand this is not a fair comparison. Microsoft is a a $2 trillion company. They can afford to have an army to accomplish all this.

And I’m not saying that the Solid project isn’t doing this. What I am saying is there’s a chance to enhance and enrich what is already out there.

For example, I’m really grateful for the walkthrough that @jeffz gave to my earlier question in the thread:

@jeffz

How I would do it. A first stop for common RDF tasks is schema.org. I go there and I look up “customer” and find a number of predicates. I poke around at to see if schema has enough to cover what I need (it often does for common tasks). If something is missing, I go to the LOV ontology search engine and search for customer. I spend an hour or two poking around looking at vocabularies that cover it. All in all I’ve spent half a day or a day researching ontologies and terms which sharpens my understanding of the domain. After I’ve done this for several projects the time doing that is diminished drastically.

I’d love for that mental walkthrough to be available in the documentation, or done in a YouTube video, etc. Anything that is a channel for others to not have to do through what I just did in this thread, which is: “How do I even start this?” And yes, I could continue to Google for more examples, but in my view, just put it on the SolidProject.org’s documentation pages: one less click and Google search to have to do; reducing the time to learning and code for any developer who’s come to SolidProject.org and is just trying to “figure it all out.”

I’m probably wrong on all this, and maybe I’m just not good at being educated and finding answers on my own; but that’s something that has been lurking around in my head for the past few days.

What problem are we trying to solve?

@aschrijver

The practical path . Defining ways to have secure personal data vaults that are decoupled from their application, and where the linked data in them increases the potential for semantic interoperability (lowers the barrier to reuse). Comprehensive, mostly existing standards suffice.

This is something I’ve been thinking about for awhile.

At the root, we are trying to give internet citizens more authority over their data. Data breaches, identity theft, surveillance capitalism, I think we all agree these are “bad things.”

When I say giving citizens authority over their data, I define this to mean:

• Giving users the ability to define where data about them is stored. When I sign up at Amazon.com, my order history, shipping address, etc is stored on their servers. Why can’t I have my data on my server?
• Giving users the ability to define access rights to their data. If I don’t want Amazon to have access anymore to my data, why can’t I revoke it? (There’s a big disclaimer here, which I’ll acknowledge in a second.)
• Determining where my data can be used. If I write up a post on Facebook, and then later decide I don’t like Facebook, why can’t I just move my data to Twitter? Or, a more common example: if I decided I don’t like Spotify, how can I move my playlists to Apple Music? This topic, as I’m sure others are aware of, is about data portability or interoperability.

As mentioned, there is a big disclaimer on item #2 from above: access rights to data. Once someone has read data about you, even once, all bets are off on how it’ll be used. This is something that Solid admits as well, and to be clear, this problem already exists today. Now, it’s been suggested that perhaps the way to solve the above is by legal measures, but that’s a topic I don’t want to go into that right now.

Now we come to the first topic I opened with and that others have already pointed out…

Developing with RDF

@NoelDeMartin

But there’s a caveat to that. RDF is not hard; but choosing a vocabulary for your app is hard, and I think that’s where the issues arise. However, if you don’t even try to be interoperable, it’s very easy to create your own vocabulary. You just create a class and properties like you would in a normal object oriented programming language.

I appreciate the clarification here. I didn’t think about this, but it’s true that I don’t even have to try and make it work with everyone else…

@NoelDeMartin

I don’t agree with this part, because RDF/Solid has an inherent advantage over SQL, CSV, or whatever. In Solid, even if your vocabulary is unique to your app, the data is available to users. So even if you made up a vocabulary and no other app uses it, the community will be able to start using your vocabulary, or implement tools to convert from your data to other formats, without your involvement. Using a traditional architecture, the data will be enclosed in your server and you need to implement a custom API if you want to expose it. I wrote a blog post talking about this, maybe you find it interesting: Interoperable serendipity .

I also appreciate this, because in theory, if I want to put in the minimum amount of effort to claim “Hey, my app gives users freedom of data!” I wouldn’t be wrong… I’d just be a pain because I didn’t put in my effort to make it use a well known vocabulary. But that is an advantage of RDF.

Before I came back to Solid this month, I had been thinking about ways to give users authority over their data; but rather than implementing the solution via protocols a few years back (by my estimation, actually about the same time that Solid and Inrupt were announced), I wanted to solve it at the data layer. Specifically, I thought the solution to where data is stored and access rights could easily be solved if we simply modified the way existing relational databases worked. So I’ve spent the last few years attempting to write my own database system with no prior systems programming experience. As you can imagine, it has not gone well I did a write up of the high level concept here on my blog:

https://dynamorando.com/blog/aboutdrummerdb/

Which itself is about the third or fourth time I’ve tried to implement this idea I had of “cooperative database systems.” The repo is a paper that I wrote (rather poorly) of a bunch of ideas that I had on how to maybe make this work.

The advantage in my view was this: Depending on implementation, it would give developers less of a surface area to have to grasp. My intent was that if we just introduce a few new concepts and new SQL keywords, we could make this work quickly for existing programmers today. Developers already understand SQL, we just need to alter the data tier a little bit to make it work.

The disadvantage to this is that we still don’t really make data portable. I also had thought about this, and in my database implementation I actually tried to hand wave this problem away by making the database schema by default public. Either by publishing the full database schema to all participants of the database system, or by making it a public read-only endpoint that could be queried.

Back now to RDF and to parts of why I started this thread: I’m all for using something that already works, and if RDF works, I’m all for instead directing energy towards something that already works. As someone once said, it’s better to steal someone else’s good ideas rather than spending your time inventing your own bad ones.

So as of today, I’m still trying to understand if the lack of adoption of RDF is that it’s not actually hard, it’s just not been advertised well, or if the tooling isn’t there, or if it’s lack of an external impetus: i.e. data protection laws that would just drive tech to more adoption of something like RDF.

So far, thanks to all of you wonderful folks on this thread, I’m coming 'round to the notion that -

• RDF, in particular, triples are a foundational concept like rows, columns, tables, and keys in a database system; and just like anything new, these concepts take a little bit of getting used to
• RDF is not hard so long as you don’t care about making it interoperable
• If you do want to make it interoperable, it will take a little bit of effort, but this can be overcome over time for a developer with experience (and maybe with more advertising on the internet)
• There’s plenty of tooling available to work with RDF - depending on how you want to work with RDF. If you want to work with it natively, there’s probably already libraries available. If you want to abstract it away to work with it in a more object oriented format for example, there may be some tooling there, but not fully fleshed out.

If you’ve made it this far, thanks again, and thanks again for your patience and for everyone’s sharing of ideas and encouragement.