Richard Cyganiak

Also known as “cygri”.

I’m a software engineer based in Ireland. I’ve previously been at FU Berlin, HP Labs Bristol, DERI Galway, and Insight Centre for Data Analytics. Now at TopQuadrant, I work on the vocabulary manager TopBraid EVN.

Experience

• I’ve served on a number of W3C WGs (RDF, RDB2RDF, GLD, LDP).
• I’m a somewhat prolific author of metadata vocabularies (VoID, DCAT, QB, DDI-RDF, XKOS).
• I'm a somewhat prolific creator of open source projects (Pubby, D2RQ, Tarql).
• I run a registry for RDF namespace prefixes (prefix.cc).
• I've created the “LOD Cloud Diagram”.

Agenda in the RDF Data Shapes WG

• As a user of Semantic Web technologies, I want to apply data shapes to the validation of RDF Data Cubes, SKOS vocabularies, and DCAT catalogues.
• As someone interested in bringing the Semantic Web to broader audiences, I want data shapes as a simple yet powerful addition to the data modeller’s toolbox.
• As a fan of SPARQL, I want data shapes to be aligned with it.

In my standards work, I try to be guided by the principle of advancing the RDF stack towards application areas where it has already proven to be successful. That being said, I also like RDF’s historical baggage and all the alluring yet impractical pie-in-the-sky visions.

Working notes

Below is my scratchpad for notes and stuff.

Work in progress

• Normalization Requirement
• Dataset Validation Requirement
• SPARQL Requirement

Links

• “Fundamental issues”
• pfps: A SHACL specification based on SPARQL, and in the wiki
• pfps: Differences between the SPARQL-based proposals
• Documentation on Wikidata constraints
• Jose's comparison
• Orri Erling's blog post on hints for performance optimization
• List of all WG resolutions

Other notes

• Issues of interest: Inference (ISSUE-1), Recursion, Punning, Inheritance

My goals

• Constraints should be expressed in RDF. That is, a shapes document is an RDF document.
• Punning between shapes and classes: I want to be able to attach constraints directly to a class my:Person, without requiring a separate resource my:PersonShape. This is because I often model “record classes”, and keeping straight that some modelling constructs are “classy” while others are “shapely” is confusing and unnecessarily complicated.
• Triggering via rdf:type: { x a my:Person } should trigger any constraints on my:Person. This is required to make punning useful, I think. When modelling “record classes”, the distinction between shapes and classes should blur. Requiring a different predicate to trigger the constraints wouldn't make sense with punning. {x sh:instanceShape my:Person } in addition to the rdf:type triple would be weird.
• Inheritance: { my:Person rdfs:subClassOf your:Person } should apply constraints on your:Person to things of type my:Person. I suppose this could be done by invoking RDFS semantics, but could something more minimalist work?
• Database-style semantics, not logics-style semantics. SHACL should work on the graph level and be as unconcerned as possible with the “semantics” (in the “RDF Semantics” or OWL sense) of the graph. SPARQL is a good paragon for this style.
• SPARQL semantics. I believe that SPARQL is the most successful part of the SemWeb stack so far. I take it for granted that SHACL implementers have cheap access to SPARQL engines. I think that SHACL should be based on SPARQL, and should add as little as possible to SPARQL. Implementers can optimise by implementing things in different ways, but if I already have a SPARQL engine, implementing a basic SHACL validator should be almost trivial. I am unconvinced about the importance of scenarios where SHACL is to be used without the presence of a SPARQL engine. There could be a “standard library” of templates/macros that can be implemented without SPARQL in such environments.
• I acknowledge scenarios where parties B and C want to express “local” constraints over classes defined independently by party A. I'm not entirely opposed to allowing “non-classy” shapes, but have not seen compelling evidence that these use cases can't be addressed with a punning-style solution.

Observations

• pfps is concerned that asserting { x a MyShape } makes triples true.
• pfps is concerned that the language may use RDFS vocabulary inconsistently, or reinvent RDFS badly.
• hknublau doesn't want to have ldom:extends and ldom:instanceShape and ldom:classShape at all, because rdfs:subClassOf and rdf:type do the same job.
• EricP wants SHACL to be implementable when you don't have a SPARQL engine.

Archive

• S14 Revision (migrated to User Stories)
• schema.org User Story (migrated to User Stories)
• SPARQL proposals (sent to list)
• JSON User Story (migrated to User Stories)
• Coverage Requirement (not pushing this)