EasierRDF

This repository is for experimental/exploratory work on making RDF easier to use, with the goal of making it easy enough for average developers (middle 33% of ability). By "RDF" we mean the whole RDF ecosystem -- including SPARQL, OWL, tools, standards, educational materials, etc. -- everything that a developer touches when using RDF. Our plan:

• focus and coordinate community efforts;
• build on existing standards whenever possible;
• launch additional W3C Community Groups to tackle specific areas of need, including
  • n3-dev Community Group, for standardizing N3 rules; and
• contribute to (and benefit from) related efforts, such as the W3C Graph Data Workshop in March 2019, which prepare the path for launching new standards work at W3C.

Introduction

The value of RDF for graph data has been well proven, in many applications, over the 20+ years since it was first created. However, 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 viewed as a viable choice for many use cases that would otherwise be an excellent fit.

This work seeks to build upon our experience with RDF to examine how we can make it easier to use. What aspects or gaps have caused difficulty? How can RDF better support features that users commonly need and other graph databases offer? How can we make RDF -- or a successor -- easy enough for average developers?

At the same time, businesses are now showing a rapidly growing interest in graph data. Businesses have used relational databases for many years, but it is costly to adapt database schema and applications in response to evolving application needs. Other graph and NoSQL databases have emerged to help meet this need. Unfortunately, there is a lack of interoperability across existing graph data solutions, motivating interest in open standards for an interchange framework. RDF is an appealing vendor neutral framework for graph data, and is well positioned to take on the role of an interchange framework. Although this interest in RDF as a graph interchange framework arose independently from the effort to make RDF easier, and has different goals, there is a natural overlap in motivation, and both efforts can benefit each other.

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.

How to contribute?

We welcome contributions. A good place to start is to review the issues list, categorized below. Please feel free to start a new issue if none of the existing ones are a good match. You can also send comments to the mailing list: [email protected].

Intellectual property rights

This work is being performed under the W3C rdf-dev Community Group and is subject to the W3C Community Contributor License Agreement (CLA).

Issue topics

Issues and ideas are recorded in our issues list and divided into the categories below using issue labels. The lists below are not auto-populated, so click on the category name below to see the latest list.

Category: big ideas: For major ideas that span multiple issue categories

• Issue 68: Idea: Record stronger alternative definitions of ease
• Issue 34: Idea: Higher-level RDF language
• Issue 33: Idea: Build powerful query engines
• Issue 32: Idea: Build JavaScript libraries that work in the browser
• Issue 31: Idea: Base Linked Data on a JavaScript API
• Issue 30: Idea: Attract JavaScript front-end developers

Category: tools: For RDF tools

• Issue 53: Lack of good forms-based end-user editor
• Issue 52: Transparently merge rdf: and rdfs: namespaces
• Issue 43: Nobody knows who does what with what
• Issue 40: Spoggy easy create & read graphs
• Issue 39: SPARQL Triplestore and Reasoning Performance
• Issue 38: Lack of Full OWL2 Support in Triplestores
• Issue 37: Lack of RDF Visualisation Software
• Issue 35: Lack of a Good Editor
• Issue 33: Idea: Build powerful query engines
• Issue 5: Moribundity of Tools
• Issue 4: Overview of an RDF triple store
• Issue 3: Lack of automated feedback / validation
• Issue 2: Tools are scattered

Category: education: For documentation and education

• Issue 59: Reduce the jargon
• Issue 58: Confusion between RDF and Linked Data
• Issue 41: Idea: Material to be put in an undergraduate DB or WebDev unit
• Issue 11: Rejection of SQL and OO as Metaphors
• Issue 10: Lack of a Canonical Example
• Issue 9: Lack of Technology Framing
• Issue 8: Beginner friendly support
• Issue 7: Beginner friendly tutorials / documentation
• Issue 6: No clear entry point

Category: usage: For issues around RDF usage in practice

• Issue 66: Dereferencing RDF, RDFS & OWL in a browser should return human-friendly versions
• Issue 65: Do not use anonymous classes
• Issue 49: Popular use cases for graph data
• Issue 43: Nobody knows who does what with what
• Issue 16: Easier-to-use competitors
• Issue 15: Define an easier profile of RDF
• Issue 14: Namespaces are lost in the RDF model
• Issue 13: Namespace proliferation
• Issue 12: IRI allocation

Category: language features: For language features of RDF itself -- model and syntax

• Issue 62: Retain relative URIs at the RDF model level
• Issue 61: Simplified Reification
• Issue 57: Composition of named graphs
• Issue 52: Transparently merge rdf: and rdfs: namespaces
• Issue 51: Relationship to the Web of Things
• Issue 48: Different kinds of identifiers
• Issue 45: Property Graphs
• Issue 42: Maybe "datatype" should be in the RDF Graph explicitly
• Issue 25: Vocabulary for new semantic extensions
• Issue 24: Decouple semantics from data model
• Issue 22: Language-tagged strings
• Issue 21: Literals as subjects
• Issue 20: Standardized n-ary relations (and property graphs)
• Issue 19: Blank nodes
• Issue 17: IRI reuse and synonyms

Category: related standards: For RDF-related standards

• Issue 64: Mappings between shape languages
• Issue 60: transparently switch between CWA and OWA
• Issue 29: No standard way to map a JSON predicate to a URI
• Issue 27: Lack of a standard rules language
• Issue 26: Lack of standard RDF canonicalization

Category: easier profile: For candidate features of an easier profile of RDF

• Issue 56: OWL is too hard
• Issue 50: Profile: Exactly one type per representation of a resource

Category: experiments: For demonstrations exploring the design space

Uncategorized

Search for issues with no category label.