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

Fully agree William.

-- https://josd.github.io/ <http://josd.github.io/>


On Sat, Mar 16, 2019 at 9:15 PM William Van Woensel <
william.vanwoensel@gmail.com> wrote:

> 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 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.
>
>
>
>
>
> William
>