- From: Martynas Jusevičius <martynas@atomgraph.com>
- Date: Tue, 15 Feb 2022 23:59:54 +0100
- To: Hugh Glaser <hugh@glasers.org>
- Cc: Chris Mungall <cjmungall@lbl.gov>, Orie Steele <orie@transmute.industries>, Mike Prorock <mprorock@mesur.io>, Dan Brickley <danbri@danbri.org>, David Booth <david@dbooth.org>, Frederik Byl <frederik.byl@gmail.com>, Semantic Web <semantic-web@w3.org>, Matthew Lange <matthew@ic-foods.org>, Harold Solbrig <solbrig@earthlink.net>
On Tue, Feb 15, 2022 at 11:04 PM Hugh Glaser <hugh@glasers.org> wrote: > > > > > On 15 Feb 2022, at 20:37, Martynas Jusevičius <martynas@atomgraph.com> wrote: > > > > My point is that JSON is no more an alternative to Tensorflow than it is an alternative to RDF graphs. Both ML and KGs are rather complex technologies solving complex problems, with application spaces that are larger and/or different from what is usually done with JSON. So this EasierRDF debate is comparing apples to oranges from the start. > > > > > Perhaps your idea of solving “complex problems” illustrates some of the difficulty in the discussion. > > I want to use KG to solve *simple* problems (as well as complex ones, perhaps). > And I would like to use SW & LD technologies. > (And I suspect that there are many others who do too.) > Not least because it will enable me to make my work more complex as time goes by. > > If you want to tell me to go and use something else because SW+LD are only for "complex problems", then do so. > If someone wants to claim they are suitable for simple problems as encountered every day by WebDevs, then that is a hard claim to substantiate, although I don’t see anyone trying to do that, here, so maybe they aren’t. If simple problems are a subset of complex problems, then a specification would be designed for complex problems? The constraints are not the same. It doesn't mean that you cannot build simple *solutions* with RDF. It's worth trying to look at first principles, and consider that a machine-readable web can be conceptualized as a giant table of quads (its subsets under different authorities) and CRUD interactions executed on it. Building on that, the RDF-based architecture becomes generic, data-driven, declarative. Which gives 100% extensibility, theoretical foundation, rapid development, diminishing cost of change, new features etc. This is the same idea behind Dave McComb's books, Software Wasteland and The Data-Centric Revolution: https://tdan.com/the-data-centric-revolution/18780 This is a software architecture I call simple, not the ability to shoehorn RDF into the most popular technology or the one I'm most used to. That is making it "easy", and it does not equal "simple". Quoting Rich Hickey, the creator of the Clojure language (which had some inspiration from RDF): "If you ignore complexity, you will slow down. You will invariably slow over the long haul. [...] If you focus on ease, and ignore simplicity, you will be able to go as fast as possible from the beginning of the race, but the complexity will eventually kill you." From this talk: https://www.youtube.com/watch?v=LKtk3HCgTa8 > > And we should tell Frederik Byl SW is the wrong tech for what he wants? > > But it still begs the question: > If I want to use, as you say > > KGs are rather complex technologies solving complex problems > (KGs to solve complex problems) > why is Neo4J apparently so much more successful in terms of KG adoption than our SW KG technology? Maybe the VC capital could be part of the reason: https://neo4j.com/press-releases/neo4j-announces-seriesf-funding/
Received on Tuesday, 15 February 2022 23:00:18 UTC