Link to an article describing an idea for an RDF killer app, written in the hope of prompting discussion here this forum. I’m new to semantic web concepts so please forgive the many incorrect assumptions I am sure to have made ! I hope you find it an interesting read anyway.
1 Like
Some interesting ideas here. You may be interested in our Solid Practitioners group (see GitHub - solid-contrib/practitioners: A hub for Solid developers ) which has the motto - “a hub for putting the Solid vision into practice.” It is actually an attempt to bring together the two groups you mention - practitioners and coders but focusing on coders who are creating things to be put into practice, so similar to your ideas. We meet twice a month online (see link above for details) and can also be reached in the chatroom at https://matrix.to/#/#solid-practitioners:matrix.org.
Thanks Jeff - Will look forward to taking a dive into that material. (By the way - interesting to see the word practitioners is already established in this context - I was a little unsure about introducing it but am feeling better about that now 
)
Yes :-), I was a bit wary to introduce the term “practitioners” when I founded the group, but I feel it is especially important for Solid. We have specification writers, ontology creators, academic projects, and many other important aspects of Solid that are at least one step removed from where Solid exists in a social context in the real world. Leaving out the question of how the web would play out in the real world turned disastrous for the first web, let’s not make the same mistake again.
I enjoyed reading it. One of your assumptions is that working with the information is more important to practitioners than sharing the data.
I’m not sure of that premise. But even if I take it axiomatically, there is still the problem the solo practitioner has with sharing the data with their future self. I know I’ve found myself in that situation. RDF seems more portable than many alternatives.
From this starting point an RDF tool offering similar functionality to ORM tools for relational databases might help. Such a tool could use explicit structure from the coding model to configure and manage RDF storage which reflected the same structure, thus piecing together the building blocks on behalf of the practitioner.
I’m not sure I understand this part. RDF is naturally data-oriented. It’s easy in ways that a spreadsheet is easy because there is no abstraction in between.
And ORM is object-oriented. It places a model on top of an English-langauge oriented data query language (SQL). So the whole thing is a mess of indirection.
So can you tell me more about what you are thinking of here?
I’ve finally had time to read through this interesting article. You make many good points.
One important thing you seem to overlook is Solid’s decoupling of data and applications. A data source is only truly open if it can be accessed by many different methods. This is a selling point for individuals who are tired of siloed apps whose algorithms and UI do not allow free access to the data or provide user-controlled interfaces. So interoperability is not just about sharing data, it is also about having multiple ways to access the data.
I think single-sign-on and data privacy are other key selling points of Solid.
While I’d agree that a low-code killer app for individuals is desirable, I disagree that it is the only or even primary way of getting Solid adopted. Many, perhaps most human-computer interactions take place within the context of organizations, not individuals - universities, enterprises, government agencies and nonprofits are all key to broad adoption. Yes there is a need for individual demand to stimulate adoption but getting governments and organizations on board is critical.
I also don’t like your final illustration which places the loop between storage, computers, and brains. What is left out is that those brains exist in a social context. The task is not simply to make data processable by brains but to organize it in such a way that it has a practical impact on the social context the brain exists in.
I define “practitioner” somewhat differently than you. I agree that it represents the people who help make Solid have a practical impact in people’s lives. Whereas you separate this into users and coders, I include both users and those coders who interact directly with users. Specification and library writers may or may not come into contact with the end users of their products whereas application developers need to interact directly with the end users of their products. It is this group of coders who have the task of working with individuals and organizations to develop tools with meaningful practical impact. The coder/practitioner stands at the fulcrum between, on the one hand community members, domain experts, project managers, and policy makers, who have real-world needs and requirements and on the other hand specification writers and infrastructure developers who create the tools the coder/practitioner use to create tools that meet the needs and requirements.
1 Like
Many thanks schmudde and jeffz for reading and responding. I will digest and reply 
I’m keen to reply here but with seasonal commitments and a few extra unexpected ones its now likely to be after Christmas. All the best, Gordon
Thanks for these thoughts schmudde. Here are replies to some of your individual points and questions.
“WORKING WITH THE INFORMATION IS MORE IMPORTANT TO PRACTITIONERS THAN SHARING THE DATA … I’M NOT SURE OF THAT PREMISE”
Yes, working with the information is more important to some practitioners and less important to others. You’re right that I’m assuming the former premise, but simply because that’s where my interest is focused. A specific category I have in mind is people whose work generates information on an ongoing basis, and who want to develop ways of capturing and using that information, either individually or in a team. Many scientists, engineers and analysts fall into this category, and these are the people I have in mind with my use of the word “practitioner”. A problem has emerged for me though : jeffz has already put the same word to good use in a different sense, so I’m thinking of switching vocab - perhaps I could use craftsman or datasmith instead of practitioner to side-step confusion - I’m going to start tentatively here by switching to datasmith.
I like your neat concept of sharing data with one’s future self, but we might be talking about slightly different types of sharing. If I understand correctly then you’re using the word “sharing” in the sense of storing-information-in-a-way-which-makes-it-navigable/discoverable, which is perfectly reasonable. In contrast I was using the same word in the sense of making-information-available-to-remote-clients-in-a-standard-way, as the web first allowed people to share their non-semantic information on the internet using HTML. Information delivered as HTML, however, is clearly unsuitable for consumption by datasmiths so RDF extends the web to make web-sharing useful to datasmiths. I will aim to make the article clearer by disambiguating my use of the word sharing. Regardless of this I agree with you (from the limited understanding I have so far) that RDF appears to have uniquely exciting and compelling strengths including portability. The big problem I perceive is that these strengths are very difficult to experiment with as a novice and get a quick gut feel for.
“I’M NOT SURE I UNDERSTAND THIS PART. RDF IS NATURALLY DATA-ORIENTED. IT’S EASY IN WAYS THAT A SPREADSHEET IS EASY”
Yes I see that RDF is naturally data oriented, and I have little doubt that once familiar it feels easy in retrospect. From a novice perspective, however, I don’t see how it could be sold as easy-like-a-spreadsheet. A spreadsheet is based on a single self-contained application which a novice can reasonably be expected to install, open and follow their nose with. I’m not seeing any such application which an RDF novice could use.
“PLACES A MODEL ON TOP OF … SO THE WHOLE THING IS A MESS OF INDIRECTION … CAN YOU TELL ME MORE?”
Yes sure. The messiness you describe is the same thing that the phrase in my article “excessive to be representing dual similar or identical structures separately” is aimed at describing. Furthermore the messiness is unavoidable because even if the structure is not represented explicitly in the code which consumes the data it still exists there implicitly. In all cases the datasmith must find a way of coping with the messiness you describe as “a [coding] model on top of” a storage model. ORM tools are aimed at helping to cope with the messiness when the storage model is based on SQL, but the tools are pitched more at coding specialists than at datasmiths. I’m thinking there is scope for a similar tool aimed specifically at datasmiths which helps them to cope with the messiness when the storage model is SPARQL. Without such a tool I fear the datasmith may seek a different storage model where the messiness is easier to manage.
Thanks for these thoughts jeffz. Here are replies to some of your individual points and questions.
“YOU SEEM TO OVERLOOK SOLID’S DECOUPLING … IS NOT JUST ABOUT SHARING DATA”
Yes I agree : having multiple ways to access the data is desirable, and indeed an important measure of how successfully it has been decoupled and made open. My emphasis on sharing is a reflection of the nature of the web, and I also described how RDF extends the web by allowing structure to be added. I see that structure as part of a healthy mechanism for decoupling the data. Was there anything in particular which gave you the impression I was overlooking that ?
“I’D AGREE THAT A LOW-CODE KILLER APP FOR INDIVIDUALS IS DESIRABLE”
Sorry to have given the impression I was thinking about low-code. I don’t have much experience with low-code platforms but my superficial understanding makes me sceptical. I generally see coding languages as a concise interface between computers and humans; the concept of low-code seems to undermine that interface by inserting a layer of vagueness. Although I like the idea of helping novices to quickly harness coding languages, it appears that AI assisted vibe-coding now offers a more direct route to achieving that.
“ORGANIZATIONS, NOT INDIVIDUALS”
I agree with you that organisations are key to broad adoption; but organisations are made up of individuals, and any direction which an organisation might ultimately adopt is likely to start off being championed by an individual. I would argue, therefore, that making the technology accessible to individuals is a prerequisite for subsequent adoption by organisations.
“DON’T LIKE YOUR FINAL ILLUSTRATION … WHAT IS LEFT OUT IS … SOCIAL CONTEXT”
”YOU SEPARATE THIS INTO USERS AND CODERS … THE CODER/PRACTITIONER STANDS AT THE FULCRUM”
In view of your comments here, and those by schmudde slightly earlier, its apparent I need to more clearly signal and explain my focus on a particular group of people (which I called practitioners before but now intend to call datasmiths, as described in my reply to schmudde, to avoid interfering with your use of practitioner). I recognise the need for the various different specialists you describe to cooperate to create the technology infrastructure, but there’s also a need for the resulting infrastructure to have a simple interface which an individual can grasp when they’re choosing whether or not to use the technology. I didn’t intend to imply any separation between users and coders - on the contrary I think that datasmiths (what I previously called practitioners/users) can simultaneously be coders. Let’s leave the word practitioners to be used as you define at the fulcrum, creating tools which will allow many people, hopefully including datasmiths, to use the semantic web effectively. I whole-heartedly agree that the social context is important and I would hope that any improvement in adoption of solid for datasmiths might help stimulate adoption in other areas too.
Frohes Neues Jahr !
Further to my initial reply four days after your comments I have pushed an update to the article, which I hope addresses the points you kindly raised.
Happy New Year !
Further to my initial reply four days after your comments, I have just pushed an update to the article which I hope addresses the points you kindly raised.