RE: Back from the W3C Workshop on Web Standardization for Graph Data

Hi everyone,


- rules should be convenient and concise to write and read
- a rule language should be kept simple (can be extended)

 

I think that having a lightweight notation (i.e., lacking quantifiers) is an especially interesting aspect of N3. It allows developers to use N3 at the level of complexity that suit their needs. Nevertheless, IMO this also means outfitting N3 with the necessary constructs to suit more complex use cases for developers who need them. 

 

- applications of rules are for example the alignment of different data sources using different ontologies, compliance checking (GDPR, fraud detection,...) or data validation



                Indeed, this is quite interesting. It would be great to collect some concrete use cases here (i.e., real-world examples of alignment problems that are resolved by rules).

 

There was not a uniformity of opinion if the rules should be done outside of the graph (ala SHACL/ShEx or SPARQL) or as an extension of the graph (ala N3). My personal opinion is that they should be expressed as part of the graph/dataset, which makes them more immediately available to a developer. 

 

+1. Note that this is also in line with one of the major goals of (rule-based) reasoning, i.e., extending a small core ontology with implied knowledge (easier when embedding the rules directly in the ontology).

 

Some personal takeaways after a quick read through the report:

 

David Booth: I want rules to be: 1. convenient and concise to write and read; and 2. easy to specify where and when I want to apply them.  I do not want to apply all rules to all data!  For example, I want to apply rules to only a particular named graph, or collection of named graphs.  And then I want to use those result in another named graph, for example, and compose results.

 

Having rules operate on graphs instead of RDF stores may also point towards the usefulness of e.g., scoped negation as failure and limiting the scope of quantifiers (i.e., to a particular graph) (?) We had a  <https://github.com/w3c/N3/issues/9#issuecomment-458874667> discussion on this on the GitHub page.

 

Ivan Herman: If people come to RDF, they will learn Turtle.  From Turtle to SPARQL is relatively easy, because it is based on the same syntax.   CONSTRUCT means that they are within the same syntax.  Problem w N3: too late.  It should have been done years ago, before SPARQL.  If we add n3 we force the user to learn another syntax.  If we cover 70%-80% of use cases with rules then that would be a good start.  Q: Is n3 really hard to learn?  A: Yes, n3 is different from SPARQL/Turtle.  Yet another obstacle.

 

Personally I don’t see it this way since N3 is a superset of RDF. One can start with “standard” RDF triples and, if they are so inclined, make their way up to N3 (or, even better, start out with the much more user-friendly N3 syntax with its support for lists, etc.). In their most basic form N3 rules are sets of triple patterns which is very comparable to SPARQL.

 

I fully support the notion of covering 70-80% of use cases with rules—but IMO this requires going beyond a simple rule language.

 

 

William