W3C home > Mailing lists > Public > public-n3-dev@w3.org > March 2019

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

From: Doerthe Arndt <doerthe.arndt@ugent.be>
Date: Wed, 27 Mar 2019 21:01:16 +0100
To: William Van Woensel <william.vanwoensel@gmail.com>, 'Gregg Kellogg' <gregg@greggkellogg.net>
Cc: public-n3-dev@w3.org
Message-ID: <0c97b48a-0f44-4d2d-07af-c161b6841bbe@ugent.be>
Hi William, all,

> - 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.
That is an interesting perspective. When I looked into the current 
uncertainties with N3 I always thought that it would be a solution to 
get away from implicit quantification and only use explicit quantifiers. 
Of course I only thought about formalisation and not about users. So, 
not supporting implicit quantification is not an option, noted.

You are right with the constructs.

Additionally we also need to fix the meaning of this implicit 
quantification and in the case of universals I personally think it is 
more intuitive to quantify on top-level, but I think some kind of 
testing how  the intuition of most users is could help us here.

> - 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).
How do we go further here? We already agreed on collecting concrete 
examples on git and I still didn't add that many (but I will). But 
should we additionally keep a list or something with links to concrete 
rule use cases (not necessary N3)?

Does anyone in this group use rules (not necessary N3) to map between 
vocabularies? Thinking about it: I think I do it all the time but don't 
even realised till it was mentioned in the workshop. So, I refine: Does 
anyone have a use case where rules are only applied to align 
vocabularies without further rule-reasoning?

> 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).
Both good arguments. Additional advantages of not completely separating 
rules from rdf triples I see are:

- it is possible to have a proof vocabulary (see 
http://www.w3.org/2000/10/swap/) in the language itself as we have in N3

- it is possible to use the same mechanism to search for rules on a 
dataset as for  triples

- it is possible to generate new rules from existing triples or rules

> 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 discussion 
> <https://github.com/w3c/N3/issues/9#issuecomment-458874667> 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.
The "Q" in that case was me. I really can't believe that SPARQL is 
easier to learn than N3 and I also don't think that N3 is difficult to 
learn if you know turtle. Maybe also something to be tested?

Kind regards,

> William
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
Received on Wednesday, 27 March 2019 20:01:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 27 March 2019 20:01:46 UTC