Average developers (middle 33% of ability)

[amirouche]

What does the following mean:

average developers (middle 33% of ability)

[dbooth-boston]

It is defining the term "average developers". If all software developers are ranked in their software development ability, then "average developers" is defined to be the middle 33% of those developers within that ranking.

It is admittedly an imprecise definition. The intent was to give more clarity than just saying "average developers" with no definition at all. The point is to dramatically expand the accessibility of RDF, to make it easy enough for most developers.

Do you have other suggestions for defining the term?

[amirouche]

It is difficult to write, and prolly difficult to read especially from someone that has not English as its primary language:

• average developer: sounds rude
• middle: I do not understand how it fits
• 33% of ability: I keep reading 33% able and 66% disabled

Do you have other suggestions for defining the term?

My suggestion is to avoid any qualifier that try to be precise on that particular subject. EasierRDF sounds good, to some extent it sounds like a subpar version of RDF. If the goal is to rework or improve or create new material that does not change existing specifications, then EasierRDF seems a slight misnomer.

My suggestion to rename the project, from the specific to the broad:

• RDF made easy
• Semantic Web made easy
• Semantic made easy

The issue is about "average dev..." and I vote to remove mentions of "developers ability or inability". Renaming the whole project is another issue that is less problematic.

[chiarcos]

I think "RDF made easy" would be a great name. This is what this is about, no implications about unachievable goals, no wrong expectations, and a telling name. It is even better than "EasierRDF" because even if things are being made easier, this doesn't mean they will be sufficiently easy in the end.

As for "Semantic Web made easy", that would be ok, too, I guess, but I'm not so sure "SW" works to attract people nowadays as much as it did 10 years ago. Personally, I work a lot with RDF technology, but generally stay away from OWL reasoning for any real-world tasks. Simply for reasons of scalability. (I still use OWL -- a lot, in fact -- but as vocabulary, only. So, instead of reasoning, I do directed search.) Not that it wouldn't be the coolest thing in the world if we ever had web-scale inference beyond RDFS semantics, I just don't see that happening any time soon. We should keep working towards this, of course ;)

"Semantic(s) made easy" is a bad idea, because that would be way too broad, raise wrong expectations and eventually leave people disappointed. Because it means claiming that SW-style semantics is the only thing there is when it comes to semantic technologies. It is not. We have distributional semantics in NLP, we have higher-order semantics in logics, and we have contextualized aspects of meaning in natural language ("discourse semantics") that are beyond semantics in a strict sense (lexical semantics) alltogether. Neither of these could ever be realistically covered. Once that there is a well-defined technological pathway between distributional semantics (embeddings) and knowledge graphs (~SW tech) that is appealing to mainstream developers, such a broad term could be justified, but at the moment, developments in this direction are more on the experimental side of things, and they don't necessarily make things easier, because they actually posit an additional entry bias to anyone coming from the other direction.

Am So., 28. Feb. 2021 um 22:47 Uhr schrieb amirouche < notifications@github.com>:

It is difficult to write, and prolly difficult to read especially from someone that has not English as its primary language:

• average developer: sounds rude
• middle: I do not understand how it fits
• 33% of ability: I keep reading 33% able and 66% disabled

Do you have other suggestions for defining the term?

My suggestion is to avoid any qualifier that try to be precise on that particular subject. EasierRDF sounds good, to some extent it sounds like a subpar version of RDF. If the goal is to rework or improve or create new material that does not change existing specifications, then EasierRDF seems a slight misnomer.

My suggestion to rename the project, from the specific to the broad:

• RDF made easy
• Semantic Web made easy
• Semantic made easy

The issue is about "average dev..." and I vote to remove mentions of "developers ability or inability". Renaming the whole project is another issue that is less problematic.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/EasierRDF/issues/79#issuecomment-787529061, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATZWSJVMW7KRINNY5KDIZLTBK2XVANCNFSM4YK5K3RA .

[jamesamcl]

Just discovered this repo and I agree that "average developer" sounds rude. To the point that the first thing I did was click the issue tracker to flag it, and found this issue.

I would personally remove all mention of "average developer", "middle 33%", and "ability". It comes across as trying to shift the blame onto developers for not being "good enough" to understand the RDF ecosystem, when it is rather the fault of the RDF ecosystem for being unnecessarily complex.

[namedgraph]

@udp now you're being rude :) "Average developer" sounds silly, I agree. And we can argue whether RDF is complex, but if you see it that way, it is at least necessarily complex -- nobody tried it to make it complex on purpose, it is the nature and scope of the problem it is addressing (global data interchange) that required it.

I would argue however that RDF is not complex, but we can disagree on that.

People think RDF is a pain because it is complicated. The truth is even worse. RDF is painfully simplistic, but it allows you to work with real-world data and problems that are horribly complicated.

https://book.validatingrdf.com/bookHtml005.html

The "average developer's" problem scope and RDF's problem scope does not need to overlap and in that case there's no point in using RDF or blaming anyone. But when they do overlap, RDF is usually the only real alternative as a solution.

[jamesamcl]

I did not say RDF is complex, I said the RDF ecosystem is complex. That is literally the thesis of this repository.

I am fully aware that RDF is very simple.

[dbooth-boston]

@udp , I sympathize with your desire to avoid sounding rude, but I think it is important to be as clear as possible about the goal. I don't think that a vague goal of making RDF "easier" is enough, because any tiny usability improvement would qualify as making RDF "easier", without coming anywhere near solving the central problem. I don't think that small, incremental improvements will be enough to solve this problem. I think the problem is big enough that it needs a more forceful approach.

The point of specifying "middle 33% of ability" is to set a clear success criterion. Nothing helps more to focus a problem than having clear success criteria. In short, I think eliminating the goalpost would be a big mistake, but if we can figure out a more polite way to clearly define that goalpost, that would be great.

[jamesamcl]

I don’t think it is a clear success criterion when the “ability” of a developer is not even remotely quantifiable. Something like “knowledge of C programming concepts” might be, given a well written exam. But what constitutes raw “ability” is highly subjective.

Honestly this whole thing comes across as extremely elitist and it doesn’t have to. It really sounds like you’re implying that people who work with RDF now are in the top 33% of developer ability. I don’t think this is true, you would certainly never be able to prove it, and I don’t think insinuating that potential users are worse programmers than you is a good way to win them over to RDF.

[vid]

Maybe it would be helpful to shift to something like "developers not specialized in RDF." A developer who is focused on UX or other aspects of their project may not want to practically become an expert in RDF &c, regardless of whether they are an "average developer" or not.

[amirouche]

to set a clear success criterion. Nothing helps more to focus a problem than having clear success criteria. In short, I think eliminating the goalpost would be a big mistake, but if we can figure out a more polite way to clearly define that goalpost, that would be great.

What about proficiency in terms of schooling (Master's degree or engineering school equivalent) or number of years of professional experience?

[dbooth-boston]

What about proficiency in terms of schooling (Master's degree or engineering school equivalent) or number of years of professional experience?

Those might be some indicators of ability, but I don't see what alternate success criteria you are suggesting. Can you clarify?

this whole thing comes across as extremely elitist

The point of the effort is to eliminate the existing elitism -- to make RDF "easy enough for average developers (middle 33%), who are new to RDF, to be consistently successful". (Quoted from the Guiding principles.) But if we can come up with clear success criteria that avoids calling attention to that existing (and unfortunate) elitism, then I'm all for it.

What success criteria would you suggest, to avoid talking about "average" developers? "Most developers" only covers 51%, so that doesn't seem nearly strong enough. What about "vast majority of developers"? Do you think that would be better than "average developers"?

[gkellogg]

I think the key is to make working with RDF easy and we should focus on the task and not the capabilities of the intended developers. Case in point: Ruby on Rails was created to make web application development easy. So easy that, early on, many didn’t need to really learn Ruby. That’s not to say that RoR was targeted at less capable developers. Simple things should be easy, hard things possible.

EasierRDF should focus on making it easy to work with RDF for everybody.

[chiarcos]

Am .03.2021, 00:54 Uhr, schrieb Gregg Kellogg notifications@github.com:

I think the key is to make working with RDF easy and we should focus on
the task and not the capabilities of the intended developers. Absolutely. If we really want to define the intended audience: What about
"for developers without specific background in Semantic Web technologies"?
That's certainly true for the people we're thinking about (otherwise, we
wouldn't need to discuss), it entails a certain level of technical skills,
but it doesn't say anything about qualifications in general.

Just the opposite, it has a slight motivational note: If you met other
developers before and you still consider yourself one (more than anything
else), you'll probably see yourself more or less at their level, putting
you at around 50% capabilities, or not much below, at least. Everything
else would have left you frustrated at some point and lead you to define
yourself not on grounds of your development qualities, but on the basis of
things you actually succeed in ...

The motivational part is that being able to use the outcome of this
initiative, this confirms your developer qualifications -- if you see that
as something to be proud of rather than, say, just a job. The elitist note
is not completely eliminated, but it is not offensive anymore.

[jamesamcl]

I think the suggestions from @vid and @chiarcos are a vast improvement.

[afs]

I agree that developer skills, abilities and interests aren't one some convenient linear scale. An expert in the security field is better at security than most of us.

What's more, it is not about a individual in isolation. Decision makers about technology are experts in their own area - they are not middle ground. They may not be the person using the technology directly.

We are competing for their time and attention - that's common for any change or new technology.

We slip into technology solution but just adding more technology to RDF is not helping increase it's uptake.

(In surveys: >50% of developers consider themselves better than average !!)

[amirouche]

There is a pull-request @ https://github.com/w3c/EasierRDF/pull/80

[TallTed]

I like #80. If there's still a desire (I don't think it's a need) to put some numeric in place, I suggest shifting from "the middle 33%" and similar to describe the totality of accessibility that's targeted --- i.e., "comprehensible and usable by at least 2/3 of developers who try" or even "comprehensible and usable by most developers who try".

---

Personally, I think the basics of RDF are already comprehensible and usable by all developers who exert a reasonable effort to find and read a few explainers like Understanding Data and/or any or all of those discovered here, while some, even many, complexities are beyond most --- both beyond most users, and beyond most users' needs.

This is no different from SQL, and C/C+/C++/C#, and Python, and Perl, and Ruby, and Scala, and Excel, and Word, and Powerpoint, and BASIC, and, and.... The basics are basic, and the complexities are complex. RDF tooling --- including such things as RDF serialization linters, OWL and other ontology visualizers, visual SPARQL query builders, SPARQL query optimizers, and many more --- does lag behind. Similar lag --- and worse! --- was seen with every other technology I mentioned.

Making things easier is always a laudable effort, and I don't think it needs precise numeric evaluation to be so.

[dbooth-boston]

There is a pull-request @ #80

Inspired by @afs 's suggestion, I have made a counter proposal in PR https://github.com/w3c/EasierRDF/pull/85 to s/average/most mainstream developers/g. What do others think?

[TallTed]

85 also works for me.

[amirouche]

I prefer #80 because I am not comfortable with the word "mainstream". And "most mainstream" sounds heavy.

[TallTed]

Perhaps simply tweak #85 to s/most mainstream developers/most developers/g?

(And perhaps retitle this issue to Rephrase problematic "Average developers (middle 33% of ability)"?)

[gkellogg]

Maybe just “many developers”.

[afs]

That would work.

Most (as in "majority") developers don't work with data at this level in any form and if they work with "data" as the focus, they use libraries and frameworks.

[dbooth-boston]

Perhaps simply tweak #85 to s/most mainstream developers/most developers/g?

I think the word "mainstream" helps to clarify that the goal is make it easy enough for developers who are NOT already familiar with RDF. However . . .

I prefer #80 because I am not comfortable with the word "mainstream". And "most mainstream" sounds heavy.

In the interest of reaching consensus I'm willing to drop the word "mainstream" if needed.

Maybe just “many developers”.

I would object to that. I feel that would weaken the goal so much that it would be nearly meaningless. I think it is important to have a goal that really is trying to make RDF easy enough for most developers.

PR #86 drops the word "mainstream", so overall it is changing "average developers" to "most developers". Folks, please indicate your agreement or disagreement with this attempted compromise.

[TallTed]

86 is also fine with me.

[dbooth-boston]

@amirouche , @chiarcos , @udp , @namedgraph , @vid , @afs , what do you think of PR #86? Does that seem like a reasonable compromise?

[vid]

I agree with most people that it's mostly better. (=

[amirouche]

86 is great :+1:

[chiarcos]

good compromise

[dbooth-boston]

It seems we've reached consensus on this, so I've merged PR #86, and I'm closing this issue. Thanks all, for helping to reach this improvement!