Reword intro to make it more polite

[jamesamcl]

See issue #79

[dbooth-boston]

Thanks for your efforts and discussion on this, but this PR would remove all success criteria, and that would defeat a major purpose of the effort.

The point of this effort is not just to make RDF incrementally easier, but to make it substantially easier, so that RDF can finally shed its elitist reputation and be readily usable by average developers. I've used the word "average" for brevity and lack of a better term, and perhaps you or someone else can come up with better stated criteria. But we cannot solve this problem unless we face it head on.

The sad fact is that many developers are turned off by how difficult it is to do things in RDF that are so simple in other data ecosystems. That difficulty is rationalized by highfalutin claims about the importance of things like the "open world assumption" and blank nodes as "existential variables" -- claims that ultimately turn out to be untrue for the vast majority of applications. RDF does not need unrestricted blank nodes, or blank nodes as existential variables. Skolemization has already demonstrated that fact.

RDF makes newcomers feel stupid because they cannot figure out how to do something so simple as returning the items of an ordered list with each item's position. Spoiler: it really is difficult. And the fact that it is so difficult clearly indicates a failing in the RDF ecosystem.

When developers who are new to RDF come across these issues, they are not likely to research the theoretical reasons for these failings, so that they can learn to think about their problem in the "proper" RDF way. They are much more likely to toss RDF into the rubbish bin and use JSON or Neo4J instead. We need to change that. We cannot fix these problems if we just vaguely talk about making RDF "easier".

We need a clear target -- clear success criteria -- and we need to be willing to break some eggs if necessary. If the current success criteria can be improved, then definitely let's improve them. But we should not eliminate them.

[dbooth-boston]

Oops, didn't mean to close this issue.

[jamesamcl]

Thanks David. I'm not going to reply in any detail here because there is already a very long discussion about this in #79, in which all of the points in your above comment have been addressed and I believe a consensus has been reached, at least among the participating community members.

Not that this is an attempt to shut down discussion, but it would be unproductive for us to bikeshed about changes without any deciding force. I am not familiar with W3C procedures, but is there a formal voting process in place we should be following?

[afs]

s/average developers/mainstream developers/g

It is simply missing the point to use language that presumes a linear scale. Developer skill sets are multidimensional.

I cannot relate the rejection by @dbooth-boston with comments about "dramatically expand the accessibility of RDF" to the proposed changes or indeed the original text.

[dbooth-boston]

is there a formal voting process in place we should be following?

W3C strongly favors consensus, but allows formal votes when necessary. For Community Groups "The person who first proposes a group may establish the group’s initial operational agreements. Thereafter, the Chair determines the means by which the group adopts and modifies operational agreements."

s/average developers/mainstream developers/g

I like this idea! But to clarify that we are not just talking about some mainstream developers, I would propose one friendly amendment: s/average developers/most mainstream developers/g

With that change, I would be comfortable dropping the "middle 33%" and "average" language. How would that sound to others?

[dbooth-boston]

I think this was resolved quite a while ago, so I'm closing this.