Toward easier RDF: a proposal

On 10/18/2018 05:09 PM, Dan Brickley wrote:
 > There are serious frustrations that come with trying to use
 > RDF (and RDFS/OWL/SPARQL, JSON-LD, RDFa, Turtle, N-Triples
 > et al.), . . .  [ . . . ] If there is to be value in having
 > continued SW/RDF groups around here, it's much more likely to
 > be around practical collaboration to make RDF less annoying
 > to work with, . . . .

Perfect lead-in!  For many months I've been working up the
gumption to raise this topic on this list.  I guess now is
the time.  :)

The value of RDF has been well proven, in many applications,
over the 20+ years since it was first created.  At the
same time, 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.

For anyone who might be attempted to argue "But RDF is easy!",
please bear in mind that *you*, dear reader, are *not* average.
You are a member of an elite who grok RDF and can work around
its frustrations and bizarre subtleties.  And for anyone who is
tempted to argue that we just need to better educate the world
about RDF: Sorry, but no.  I and many others have been trying to
do exactly that for over 15 years, and it has not been enough.

Using RDF is like programming in assembly language.
It is tedious, frustrating and error prone.  Somehow, we
need to move up to a higher, easier, more productive level.
One bright light in our favor is that RDF already provides a
very solid foundation to build upon, based on formal logic.
Another is that graph databases -- though not specifically
RDF -- are now getting substantial commercial attention.

Difficulty of use has caused RDF to be categorized as a niche
technology. This is unfortunate because it limits uptake and
prevents RDF from being a viable choice for many use cases that
would otherwise be an excellent fit.  Use cases that depend
on broad uptake can *only* be achieved when RDF is usable by
*average* development teams.

I've been puzzling this problem for several years.  I spoke
about it at the US Semantic Technology Symposium (US2TS) early
this year[1], and Evan Wallace and I will lead a session at
the 2019 US2TS[2] in March to address it further.  See also
excellent observations by Sean Palmer[3], Dan Brickley[4]
and Axel Polleres et al[5].  I have collected a few ideas,
but I do not have complete answers.  I think it will take a
community effort -- and more new ideas -- to fix this problem.

PROPOSAL:
To address RDF ease-of-use head-on, as a community effort.

Guiding principles:

1. The goal is to make RDF -- or some RDF-based successor --
easy enough for *average* developers (middle 33%), who are
new to RDF, to be consistently successful.

2. Solutions may involve anything in the RDF ecosystem:
standards, tools, guidance, etc.  All options are on the table.

3. Backward compatibility is highly desirable, but *less*
important than ease of use.

SPECIFIC PROBLEMS

The rest of this message catalogs some of the biggest
difficulties that I have noticed in using RDF.  YMMV. They
are not necessarily in priority order, and there may be
others that I missed. One goal should be to prioritize them.
Some have obvious potential fixes; others don't.  I've also
included some potential solution ideas.  I am interested
to hear your feedback, as well as any other problems
or solution ideas that you think should be considered.

Please MAKE A NEW SUBJECT LINE if you reply about one of the
specific problems below, to help organize the discussion.

1. Tools are scattered.  How to find them?  Which to use?
Every team wastes time going through a similar research and
selection process.

One idea: create a bundled release of RDF tools, analogous
to a standard LAMP stack, or Red Hat or Ubuntu; so that if
someone wants to use RDF all they have to do is install that
bundle and they're ready to go.

2. IRI allocation.  IRIs must be allocated for almost everything
in RDF: things, concepts, properties, etc. -- both TBox
(ontology/schema) and ABox (instance data).  IRI allocation
is easy in theory but hard in practice!  "Cool IRIs" are
dereferenceable http(s) IRIs, but domain registration costs
money and is not permanent.  Dereferenceable IRIs require a
commitment that many RDF producers are not ready/able/willing
to make.  And even when the RDF producer is willing to use
dereferenceable http(s) IRIs, how exactly should those IRIs
be formed?  There are many possible solutions, but no standard
best practice.  Again every team has to figure out its own path.

3. Blank nodes.  They are an important convenience for RDF
authors, but they cause insidious downstream complications.
They have subtle, confusing semantics.  (As Nathan Rixham
once aptly put it, a blank node is "a name that is not
a name".)  Blank nodes are special second-class citizens
in RDF.  They cannot be used as predicates, and they are not
stable identifiers.  A blank node label cannot be used in
a follow-up SPARQL query to refer to the same node, which
is justifiably viewed as completely broken by RDF newbies.
Blank nodes also cause duplicate triples (non-lean) when the
same data is loaded more than once, which can easily happen
when data is merged from different sources.  And they cause
difficulties with canonicalization, described next.

4. Lack of standard RDF canonicalization.  Canonicalization
is the ability to represent RDF in a consistent, predictable
serialization.  It is essential for diff and digital signatures.
Developers expect to be able to diff two files, and source
control systems rely on being able to do so.  It is easy with
most other data representations.  Why not RDF?  Answer: Blank
nodes.  Unrestricted blank nodes cause RDF canonicalization
to be a "hard problem", equivalent in complexity to the graph
isomorphism problem.[6]

Some recent good progress on canonicalization: JSON-LD
https://json-ld.github.io/normalization/spec/ .  However, the
current JSON-LD canonicalization draft (called "normalization")
is focused only on the digital signatures use case, and
needs improvement to better address the diff use case, in
which small, localized graph changes should result in small,
localized differences in the canonicalized graph.

5. SPARQL-friendly lists.  It is very hard[7] to query RDF
lists, using standard SPARQL, while returning item ordering.
This inability to conveniently handle such a basic data
construct seems brain-dead to developers who have grown to
take lists for granted.

Apache Jena offers one potential (though non-standard)
way to ease this pain, by defining a list:index property:
https://jena.apache.org/documentation/query/rdf_lists.html
Another possibility would be to add lists as a fundamental
concept in RDF, as proposed by David Wood and James Leigh
prior to the RDF 1.1 work.[8]

6. Standardized n-ary relations (and property graphs).  Since
RDF natively supports only binary relations, relations between
more than two entities must be encoded using groups of triples.
A W3C Working Group Note[9] describes some common patterns,
but no standard has been defined for them.  As a result,
tools cannot reliably recognize and act on these groups of
triples as the atomic units that they are intended to represent.

This deficiency has greater significance than it may appear,
because it is subtly related to the blank node problem:
a major use of blank nodes is to encode n-ary relations.
In other words, n-ary relations are a major contributor to
the blank node problem.

Furthermore, standardized n-ary relations could also enable
direct support for property graphs[10], which have emerged as
a popular and convenient way to represent graph data, led by
Neo4J.[11] Property graphs add the ability to attach attributes
to relationships, which can be viewed as a special case of
n-ary relations.  Olaf Hartig and Bryan Thompson have proposed
conventions for adding property graph support to RDF.[12]

7. Literals as subjects.  RDF should allow "anyone to say
anything about anything", but RDF does not currently allow
literals as subjects!  (One work-around is to use -- you guessed
it -- a blank node, which in turn is asserted to be owl:sameAs
the literal.)  This deficiency may seem unimportant relative
to other RDF difficulties, but it is a peculiar anomaly that
may have greater impact than we realize.  Imagine an *average*
developer, new to RDF, who unknowingly violates this rule and
is puzzled when it doesn't work.  Negative experiences like
that drive people away.  Even more insidiously, imagine this
developer tries to CONSTRUCT triples using a SPARQL query,
and some of those triples happen to have literals in the
subject position.  Per the SPARQL standard, those triples will
be silently eliminated from the results,[13] which could lead
to silently producing wrong answers from the application --
the worst of all possible bugs.

8. Lack of a standard rules language.  This is a big one.
Inference is fundamental to the value proposition of RDF,
and almost every application needs to perform some kind
of application-specific inference.  ("Inference" is used
broadly herein to mean any rule or procedure that produces new
assertions from existing assertions -- not just conventional
inference engines or rules languages.)  But paradoxically,
we still do not have a *standard* RDF rules language.
(See also Sean Palmer's apt observations about N3 rules.[14])
Furthermore, applications often need to perform custom
"inferences" (or data transformations) that are not convenient
to express in available (non-standard) rules languages, such
as RDF data transformations that are needed when merging data
from independently developed sources having different data
models and vocabularies.  And merging independently developed
data is the *most* fundamental use case of the Semantic Web.

One possibility for addressing this need might be to embed
RDF in a full-fledged programming language, so that complex
inference rules can be expressed using the full power and
convenience of that programming language.  Another possibility
might be to provide a convenient, standard way to bind custom
inference rules to functions defined in a programming language.
A third possibility might be to standardize a sufficiently
powerful rules language.

However, see also some excellent cautionary comments from Jesus
Barras(Neo4J) and MarkLogic on inference: "No one likes rules
engines --> horrible to debug / performance . . . Reasoning
with ontology languages quickly gets intractable/undecidable"
and "Inference is expensive. When considering it, you should:
1) run it over as small a dataset as possible 2) use only the
rules you need 3) consider alternatives."[15]

9. Namespace proliferation.  It's hard to manage all the
namespaces involved in using RDF: FOAF, SKOS, DC and all the
hundreds of specialized namespaces that are encountered when
using external RDF.  Namespaces can help organize IRIs into
categories (typically based on the IRI's origin), but this
fact is nowhere recognized in official RDF specs.  Indeed,
the official mantra is that IRIs are opaque, and there are
very important design reasons for opacity.[16]  But there is
a cost: RDF is stuck in a flat, global naming space analogous
to global variables of 1960's programming languages.  Somehow,
modern programming languages deal with namespaces much more
conveniently than RDF does.  Perhaps we can learn from them,
without undermining the Web's design principles.

Related issue: the RDF model does not retain namespace info.
As such, namespaces are often lost when tools process RDF.
One partial solution might be to standardize RDF triples that
capture serialization-related information, such as namespaces,
and have tools retain them in a separate graph.

10. IRI reuse and synonyms.  In theory, RDF authors should reuse
existing IRIs, rather than minting their own.  But this makes
for messy RDF and increases the up-front burden on developers.
Consider a typical RDF project that integrates data from
multiple sources, and needs to connect that data into its own
vocabulary.  The resulting data involves both the normalized
vocabulary and the non-normalized source vocabularies,
intermixed.  The developers might be happy to adopt existing
concepts like foaf:name (for a person's name) and dc:title (for
a document title) into the project's normalized vocabulary.
But by using those existing IRIs instead of minting their
own IRIs in their own namespace (such as myapp:name and
myapp:title), it becomes hard to distinguish IRIs of the normalized
vocabulary from IRIs of the non-normalized source vocabularies.

Ideally a project should be able to use its own preferred names
(and namespaces), like myapp:name and myapp:title, while still
tying those names to existing external IRIs, such as foaf:name
and dc:title.

owl:sameAs is not great for this.  It is too heavyweight
for simple synonyms, and it is only for OWL individuals --
not classes.  Furthermore, it provides no way to indicate
which IRI is locally preferred.  It would be good to have a
simple standard way to rename IRIs or define IRI synonyms.

                           - - - -

Please USE A DIFFERENT SUBJECT LINE if you reply about a
specific problem/idea listed above, as opposed to replying
about the overall proposal of addressing RDF ease-of-use as
a community effort.  As always, comments/suggestions/ideas
are welcome.

Thanks!
David Booth

References:

1. "Toward Easier RDF", David Booth, slides from 2018 US
Semantic Technology Symposium:
https://goo.gl/H2vBYi

2. US Semantic Technology Symposium (US2TS):
http://www.us2ts.org/

3. "What happened to the Semantic
Web?" (general comments), Sean Palmer:
https://lists.w3.org/Archives/Public/semantic-web/2017Oct/0024.html

4. "Semantic Web Interest Group now closed",
"RDF(-DEV), back to the future", Dan Brickley:
https://lists.w3.org/Archives/Public/semantic-web/2018Oct/0086.html
https://lists.w3.org/Archives/Public/semantic-web/2018Oct/0052.html

5. "A More Decentralized Vision for Linked Data", Axel Polleres,
Maulik R. Kamdar, Javier D. Fernandez, Tania Tudorache, and
Mark A. Musen: https://openreview.net/pdf?id=H1lS_g81gX

6. "Signing RDF Graphs", Jeremy Carroll
http://www.hpl.hp.com/techreports/2003/HPL-2003-142.pdf

7. "Is it possible to get the position of an element
in an RDF Collection in SPARQL?", see Joshua
Taylor's answer, "A Pure SPARQL 1.1 Solution":
https://stackoverflow.com/questions/17523804/is-it-possible-to-get-the-position-of-an-element-in-an-rdf-collection-in-sparql

8. "An Ordered RDF List", David Wood and James Leigh:
https://www.w3.org/2009/12/rdf-ws/papers/ws14

9. "Defining N-ary Relations on the Semantic Web", W3C Working Group:
https://www.w3.org/TR/swbp-n-aryRelations/

10. Property Graph, Wikipedia:
https://en.wikipedia.org/wiki/Graph_database#Labeled-Property_Graph

11. DB-Engines Ranking of Graph DBMS:
https://db-engines.com/en/ranking/graph+dbms

12. "Standards for storing RDF/OWL in a property graph?", Olaf Hartig:
https://lists.w3.org/Archives/Public/semantic-web/2018Apr/0030.html

13. "SPARQL 1.1 Query Language: CONSTRUCT":
https://www.w3.org/TR/sparql11-query/#construct

14. "What happened to the Semantic
Web?" (SPARQL comments), Sean Palmer:
https://lists.w3.org/Archives/Public/semantic-web/2017Oct/0045.html
https://lists.w3.org/Archives/Public/semantic-web/2017Oct/0059.html

15. "Debunking some 'RDF vs. Property Graph' Alternative Facts",
Jesus Barras, slides 34 and 35:
https://www.slideshare.net/neo4j/graphconnect-europe-2017-debunking-some-rdf-vs-property-graph-alternative-facts-neo4j

16. "Universal Resource Identifiers: The Opacity Axiom", Tim
Berners-Lee:
https://www.w3.org/DesignIssues/Axioms.html#opaque

17. "Notation3 (N3): A readable RDF syntax", W3C Team Submission,
Tim Berners-Lee and Dan Connolly:
https://www.w3.org/TeamSubmission/n3/

Received on Wednesday, 21 November 2018 22:40:51 UTC