Re: Pragmatic Problems in the RDF Ecosystem (Was: Re: Toward easier RDF: a proposal)

On Tue, Nov 27, 2018 at 1:32 PM Steven Harms <sgharms@stevengharms.com>
wrote:

> These sites look state of the art for the pre-Clinton era. Should one
> actually
> find the W3C spec, the look-and-feel there (to say nothing of the writing
> style
> and tone) suggests "Keep moving, peasant."
>

I'm laughing, but yes. They're written in a "this is too complex for you"
style, rather than a "this isn't as complicated as you think, you can do
it" style. The specifications are, sadly, more complicated than what
they're trying to specify.

The JSON specification is my go to example here, balances technical and
simple together, and yes, we can all do this.

Said Booth:
> > a painful reality has emerged: RDF is too hard for *average*
> developers.  By
> > "average developers" I mean those in the middle 33 percent of ability.
> And by
> > "RDF", I mean the whole RDF ecosystem -- including SPARQL, OWL, tools,
> > standards, etc. -- everything that a developer touches when using RDF.
>
> While RDF is wonderfully graspable in its simplicity: triples that can be
> serialized into multiple formats; its ecosystem  of clever acronyms and
> backronyms is tedious, over-precious, and opaque.  RDF* requires the
> learner to
> hold too many cognitive circuits open before anything starts to resolve.
>

Agree, and would add that sometimes too much choice is a bad thing. This is
a reason I've always gravitated back towards N3, it's one simple(r) set of
specifications, one way of doing things, that allow me to do far more.


> In the dawn of the JavaScript frameworks (2014-ish) _everyone_ did a TODO
> app.
>

Myself and Melvin Carvalho did this in RDF+JS+HTML+LocalStorage back in
2011/12. I think Melvin has evolved it considerably for personal use, and
it's perhaps one of the few nuggets I ever contributed to that has some
part of it still used.

That is, small useful applications, as you point out, are often the
foundation and entry point for far more complex and useful ones.


> This is really an extension of E, but there's a huge gulf between some
> foaf-y
> triviality and "Model a Medical Product Ontology." Uhm, how about something
> obvious and fun (modeling board games, or card games, books,
> plays..anything?)
>

Another fine point, I would throw schema.org in to the mix here as sitting
in the middle, but in my personal and commercial experience, it's just used
for SEO, often by people who have complex anti-scrape bot protection and
cross origin stopped, so all that wonderful LD can't actually be used by
anybody but the giants for seo. There's something very sad this.


> RDF* is neither SQL nor Object-Oriented programming, but dear Mithras, SQL
> and
> OO are powerful, pervasive metaphors that most RDF* learners' mental models
> appeal to when they're learning. Why aren't we translating trivial OO code
> or
> trivial DB modeling in those metaphors to RDF*?
>

Again, agree. I've always introduced RDF this way to developers and non
developers, even marketing guys who use CSVs grok RDF when explained in
this way.

On a personal note, understanding that X bit of data can be presented or
stored as a set of triples, an object, tabular, then encoded in multiple
serializations over the wire, and transformed backwards and forwards
between any of the aforementioned, was liberating and door opening. It
shaped the way I approached simple and complex problems from that day
forth. I realized that 3/4 of my job as a developer, could be described as
just doing data transformation. CSV -> Object -> HTML often broadly
describes a read only system.

The day I fully discovered this, I looked for the tooling, because if most
of that data transformation can be automated by going in and out of
triples, then I free up 3/4 of my developer time to concentrate on doing
more fun things with the data, more functionality, logic, data linking - I
could spend my time adding more value, and thus feeling more valuable - it
never happened though. I still model this way mentally, and that has helped.


> I re-read this now and am staggered. RDF*'s a data format that's
> conceptually
> _simpler_ than SQL but which is _orders of magnitude_ harder to learn (see
> A-F,
> above).
>

Likewise, If RDF had only been Turtle, presented in a single quick spec
document (like json), then perhaps this would not be the case.


> Kathy Sierra said one of the most profound things I ever heard at SXSW in
> the
> early aughts (about the time I was dabbling with SW): "When tools are
> great,
> users say 'This tool is awesome'; when tools or docs are awful, users say
> 'I
> suck.'" After 10 years of feeling like "I suck" in RDF* land, I'm starting
> to
> wonder why I'm still trying.
>

I suck too. I've been involved in working groups, specialized task forces,
written rdf specifications, and I definitely suck, an amateur, I don't know
what I'm doing half of the time, and feel well below the level of
intelligence needed to understand all of these specifications. Sometimes
even to understand replies on this list.

Half way through learning and being involved with this side of the web, I
realized I was lacking extensive formal education, so bought, read, and
learned in order: Logic for Dummies, Calculus refresher books, Logic, a
short introduction, Schaum's set theory and related topics, Schaum's logic,
an introduction to graph theory, Schaum's graph theory, First-Order Logic,
all of timbl's design issues, multiple other resources. I still didn't feel
up to par, after a lifetime of programming and doing very complex tasks,
I'd build compiler optimisers, do cryptography challenges, even parse
asn.1 *for
fun*, I've always felt out of my depth here.

The only observation I'll add, is this xkcd https://xkcd.com/927/ - and rdf
1.2, 2, anything more-rdf, is just an extra spec to muddy the waters
further. Even if we collectively create the most useful and simple
specifications and implementations ever, just calling them RDF anything
will doom them to being an extra part of something overly complex. RDF*
exists, adding to it further does not simplify it.