- From: Matthew Lange <matthew@ic-foods.org>
- Date: Tue, 15 Feb 2022 13:42:20 -0800
- To: Nathan Rixham <nathan@webr3.org>
- Cc: Martynas Jusevičius <martynas@atomgraph.com>, 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>, Harold Solbrig <solbrig@earthlink.net>
- Message-ID: <CAHGG=WbZTUWkpJUitV+h5LMwc9uwxm_TdkRnC47ibtkxuX2GEQ@mail.gmail.com>
Thanks for looping me into the conversation Chris. While it is true that folks who studied candles had no hope of creating lightbulbs--I am not sure the distinction between the (No)SQL and Semantic/Ontology technology stacks is quite so disparate. Indeed, at icicle.ai we are focussed on bridging semantic and "traditional" (json, (No-)SQL, etc) technology stacks in order to provide on and off ramps for application-developer communities. Our tagline is "Democratizing AI"--this really means meeting people where they are at in terms of their skill levels and tooling. So in addition to building semantically native tooling, some of the "bridging" questions we're asking include: 1. How do we make it possible to easy to interrogate instantiated ontologies and then produce document/tabular assets that can be displayed/queried or otherwise computed over with more familiar application tooling? 2. How do we make it possible to ingest familiar document/tabular data and facilitate semantic tagging so that these traditional data stores become semantically enabled? 3. How do we make these tools, and their inclusion in varied (meta-) models, easier to use and "pluggable" in nature? Don't get me wrong, training in new technologies is critical for workforce development--something I think a lot about. However, I believe this doesn't need to stymie development of bridging technologies and hybrid-data stacks that facilitate broader usage and exposure. On Tue, Feb 15, 2022, 13:13 Nathan Rixham <nathan@webr3.org> wrote: > On Tue, 15 Feb 2022, 20:42 Martynas Jusevičius, <martynas@atomgraph.com> > wrote: > >> >> >> On Tue, Feb 15, 2022 at 8:46 PM Chris Mungall <cjmungall@lbl.gov> wrote: >> >>> >>> >>> On Tue, Feb 15, 2022 at 1:34 PM Martynas Jusevičius < >>> martynas@atomgraph.com> wrote: >>> >>>> When most developers only know decades old software development methods >>>> such as object-oriental and procedural programming languages and RDMBSs, >>>> then they use them as hammers and expect everything else to be dumbed down >>>> to become familiar nails. >>>> >>> >>> Sorry that has been your experience, that hasn't been mine, many >>> developers I know are keen (sometimes too keen) to apply new tools and >>> frameworks, but also exhibit a good practical sense of what tool is most >>> appropriate for the task at hand >>> >>> >>>> Imagine if this discussion happened not in the Knowledge Graph but in >>>> the AI community (EasierML?): "In our experience, developers do not like >>>> the machine learning stack (PyTorch, Tensorflow etc.), they vastly prefer >>>> JSON, TSVs, RDBMSs...". Said no one ever, because there would be no ML if >>>> this was the case. >>>> >>> >>> I don't follow the analogy here, I don't think JSON is an alternative to >>> Tensorflow. If anything this exemplifies my point, since modern ML tools >>> embrace the data stacks that developers were already familiar with (e.g >>> pandas) rather than replace them. >>> >> >> 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. >> > > Just an opinion, not a fact. >
Received on Thursday, 17 February 2022 09:35:40 UTC