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

> On Mar 14, 2019, at 9:17 AM, Doerthe Arndt <doerthe.arndt@ugent.be> wrote:
> 
> Dear all,
> 
> last week I attended the W3C Workshop on Web Standardization for Graph Data (https://www.w3.org/Data/events/data-ws-2019/index.html) where I got the opportunity to moderate the session on rules and reasoning together with Harold Boley.

It was great to see you there, and thanks for helping to chairing the session!

> For me, the most important reason to come to the workshop was to make people aware of the benefits of using rule-based reasoning on graphs in general and of N3 as a rule-based language for RDF in particular, but also to better understand the needs of the different communities regarding rules.  And I think in both aspects the workshop has been a success: there was even more interest in rule-based reasoning than I expected and the discussions we had at the session really helped me to understand where (potential) users of N3 stand and what is important for them.
> 
> You can read the minutes of our session here: https://docs.google.com/document/d/1-p_GgYizfxlGhc_j2z3W2sQUsLLGUOvNMMWV6vEtUhk/edit?usp=sharing
> 
> 
> For me the most important points are:
> 
> - rules should be convenient and concise to write and read
> 
> - syntax is very important. In case of a Semantic Web rule language it needs to be very close to existing standards like rdf-turtle.
> 
> - a rule language should be kept simple (can be extended)
> 
> - applications of rules are for example the alignment of different data sources using different ontologies, compliance checking (GDPR, fraud detection,...) or data validation
> 
> - many people like to use rules for reasoning because they are very easy to explain and understand (compared to for example OWL-DL reasoning)

I heard a desire to reuse SPARQL-like structures for doing reasoning, which I think is somewhat different from quantifier semantics from FOL/N3. 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. My interpretation of the “like SPARQL” is more in the BGP semantics, with some aspect of filtering, rather than as a syntactic representation, but this will likely elicit differing opinions and be subject so some discussion in the future.

> Given the first point I think that a representation in json-ld could also be very helpful as well (something Gregg already started). Furthermore there were many more ideas mentioned which you can find in the minutes. There was for example the desire to be able to specify where and when rules get applied to (sub-)graphs. Is that something we want to cover?

I previously shared something, inventing a syntax for describing JSON-LD terms are identifier resources, that could be interpreted as such. Other syntaxes, such as Turtle/TriG, might lean more heavily on the N3 syntax, at least in regards too `?var`.

{
  "@context": {
    "@base": "http://example.com/",
    "@vocab": "http://example.com/",
    "=>": {"@id": "http://www.w3.org/2000/10/swap/log#implies", "@container": "@graph"},
    "?x": {"@univar": true},
    "?y": {"@univar": true}
  },
  "@graph": [
    {"@id": "Julie", "parent": {"@id": "Suzie"}},
    {
      "@graph": {"@id": "?x", "parent": "?y"},
      "=>": {"@id": "?y", "child": "?x"}
    }
  ]
}

which is roughly analogous to the following N3:

:Julie :parent :Suzie .
{ ?x parent ?y } =>  { ?y :child ?x }.

> In many smaller private discussions I was made aware of  other existing rule languages and works over N3. I still have to go through my pointers to be able to report here (but I will come back to the list).
> 
> I would also be interested on your opinion about the different aspects mentioned in the minutes.

I think there’s a ways to go before the Property Graph folks ultimately embrace reasoning, but it is an inevitable requirement, and making it part of the data model I think makes it more generally available, rather than another spec that works along side the data model as SPARQL/SHACL/ShEx do.

Gregg

> Kind regards,
> Doerthe
> 
> -- 
> Dörthe Arndt
> Researcher Semantic Web
> imec - Ghent University - IDLab | Faculty of Engineering and Architecture | Department of Electronics and Information Systems
> Technologiepark-Zwijnaarde 122, 9052 Ghent, Belgium
> t: +32 9 331 49 59 | e: doerthe.arndt@ugent.be
> 
>