OWL is too hard

[dbooth-boston]

EXAMPLE:

:Library rdfs:subClassOf [ 
      a owl:Restriction ;
      owl:allValuesFrom :Book ;
      owl:onProperty :holds
      ] ;

This is a ridiculously convoluted way to say that a :Library instance has a :holds property with zero or more :Book values.

In contrast, this idea is very easy to express and understand in UML or ShEx (aside from open/closed world differences).

Is there an easier way that the most commonly needed parts of OWL could be expressed and used?

[namedgraph]

So use SHACL or ShEx, what's the problem? Just don't compare apples to oranges. SHACL/ShEx is used for validation while OWL is used for reasoning.

[dbooth-boston]

Sorry, I should have been clearer. The problem is that these concepts are too hard to read and write in OWL. It would be nice if there were easier ways -- analogous to UML or ShEx -- to write these things in OWL for use in OWL reasoning.

[draggett]

I am exploring ideas for a simple to understand rule language, and note that as yet there are no agreed rule languages for property graphs, so there is a gap for new work. I've previously worked on applying Augmented Transition Networks (ATNs) as a graphical formalism for shape rules (SHRL) and will next look at ideas for easy to understand graphical representations of production rules. The internal representation would be something simple. For my work on ATNs, I used RDF itself as this is easy to interpret and also made it simple to translate to the format needed by GraphViz for visualisation as a graph (using a web worker).

For more details, see: https://www.w3.org/WoT/demos/shrl/shape%20rule%20language.pdf and https://www.w3.org/WoT/demos/shrl/test.html

I would be happy to provide graphical examples if you provide the OWL use cases.

Note that given SHACL and ShEx, I am not trying to push yet another shape rules formalism. Rather I want to experiment with production rules for reasoning over graph data. This would be applicable to different kinds of reasoning, e.g. deductive, inductive, abductive, causal, counter-factual and so forth. I see lots of potential for reasoning based upon rational beliefs - what you've been taught (prior knowledge) and what you've learned for yourself (past experience), and note that this is much more flexible in dealing with real-world data than sound deductive reasoning, which breaks down when you have incompleteness, uncertainty, inconsistency and errors. I appreciate that this involves a paradigm shift and hence may be a little new for many people. In essence, OWL based deduction is too limited and we need to move to operational semantics based upon the applications of rules to graphs.

[namedgraph]

@dbooth-boston, is this really one of the pressing problems? You want to create a new version of OWL so you can write 4 lines instead of 5? This works, this gets shit done. A lot of people put a lot of hours and a lot of consideration into OWL, like most RDF standards.

Why not focus on RDF areas where shit is not getting done? Like, client-side libraries, documentation, UX just as examples right of the bat. Don't fix it if it ain't broke.

I think EasierRDF is well-intentioned, but as I have mentioned multiple times, it is calling for changes that will have a ripple effect across the specs as well as implementations, yet with little to no benefit. If anything, that will harm the RDF ecosystem, not strengthen it.

[draggett]

Hmm, @namedgraph doesn't that miss the point about making graphs much easier to use by the middle 33% of developers?

[namedgraph]

Not if that means breaking well-defined and widely-used standards.

Put a library on top of OWL, make a library that abstracts the complexities away and/or gives you shorthands over the syntax (if that is possible at all, without losing expressivity), but just don't touch the W3C specs.

[draggett]

As David has explained, we could layer an Easier RDF framework on top of the RDF core, and this may be practical with either no changes to the core, or a few small additions that are deemed essential. W3C specs typically evolve to meeting emerging business needs. The plan to launch a Business Group will help to clarify these needs and ensure that any standardisation work has a clear business justification.

[dbooth-boston]

@dbooth-boston, is this really one of the pressing problems?

Yes. Average developers are completely turned off by OWL. That is a pressing problem.

You want to create a new version of OWL so you can write 4 lines instead of 5?

No, I want to: (a) build on top of what we already have -- not break it; and (b) make it substantially easier to use, so that even average developers can use it, like writing 2 easy-to-understand lines instead of 5 ridiculously convoluted lines.

This works, this gets shit done.

It gets shit done for an elite few. But it gets nothing done for the majority of developers, because they cannot use it.

A lot of people put a lot of hours and a lot of consideration into OWL, like most RDF standards.

Yes, and as I've said before, we should not throw that work away. That work provides a solid foundation. That's why I favor building on top of what we have wherever possible -- not breaking it.

[dbooth-boston]

Put a library on top of OWL, make a library that abstracts the complexities away and/or gives you shorthands over the syntax (if that is possible at all, without losing expressivity)

Agreed. That's exactly what I hope we can devise, and why I recorded this issue.

[iherman]

@dbooth-boston to be fair, there is a better syntax for OWL, namely the Manchester Syntax. There are bunches of examples in the OWL 2 Primer (there are a series of buttons at the beginning of the primer to choose among various syntaxes). As far as I know, most of the OWL reasoners can accept input with the Manchester Syntax and I presume there exist converters to Turtle. The downside is that the Manchester Syntax is defined for OWL Direct Semantics only although, I presume, that covers a vast majority of OWL usage anyway.

That being said, the title of the issue is "OWL is too hard". Personally, I do not believe that a choice of syntax will make it really easier (just a bit). In my experience, for people not in the RDF world (and even, sometimes, for those in this world) it may be confusing to realize that OWL is not used to express constraints but to provide, essentially, a means to find inconsistencies and provide a license to generate additional triples. I have seen several examples of ontologies where the accompanying descriptions for terms were aiming at reinforcing constraints on the language. (E.g., if an individual is not explicitly declared to be of a certain type, then expect an error, while what this would mean is that the typing is automatically added, conceptually, to the graph by OWL reasoning.) And, I believe, the origin of all this is the fact that OWL is rooted in the Open World Assumption and many applications may not really rely on OWA.

I am not sure how these confusions can be helped for that middle 33% you are referring to. My personal feeling is that OWL should be left as is (essentially what @namedgraph said, if I understand him right), and leave it to ontology experts; let us not aim OWL for them. If we had a proper, simple rule environment for RDF, that could/would cover the large majority of applications. Explaining rules to developers that, by and large, come from an imperative programming environment is fairly straightforward. And, for constraint expression we do have SHACL which, with its SPARQL-like syntax, is closer to the core syntax of RDF, i.e., Turtle. (Although a better layer on top of SPARQL may be possible, too, but that is another matter...)

Now, do we have a simple rule environment for RDF? That is another issue...

[dbooth-boston]

@iherman , fair point. You are right that the Manchester syntax is a step in exactly the direction that I want, and I should have showed it:

EquivalentClasses(
   :Library 
   ObjectAllValuesFrom( :holds :Book )
 )

But even in the Manchester syntax it still seems non-intuitive to say that these are just equivalent classes, when from a newbie developer's perspective they are trying to define the :Library class, which is a directional notion -- not an equivalence.

Ultimately you may be right, that OWL will never be easy enough for the middle 33%, because it is rooted in the OWA, and middle-33%-ers should just avoid it. But I still think it is worthwhile to challenge the community to see if we can do better, to reach a broader user base.

[sesuncedu]

There are some mistakes in some of the comments above, (which supports the issue title).

:Library rdfs:subClassOf [ 
      a owl:Restriction ;
      owl:allValuesFrom :Book ;
      owl:onProperty :holds
      ] ;

The Manchester syntax is a bit clearer:

Class: Library
    SubClassOf: 
        holds only Book

This is a ridiculously convoluted way to say that a :Library instance has a :holds property with zero or more :Book values.

That is a bit weaker than what is being expressed, which can be verbalized as Everything a Library holds is a Book.

The weaker translation does not really have a ready OWL equivalent, as it possibly trivial, since it does not say anything about other possible non-book holdings (e.g. Maps, Board games, etc.), nor does it impose any constraints on the cardinality of Book valued holdings.

The Functional Syntax snippet using EquivalentClasses adds other problems.

That version makes any class whose instances can only hold Books equivalent to Library, which is probably not what is wanted (bookstores?).

[dbooth-boston]

@sesuncedu , thanks for the correction and comments!

[afs]

This should be filed under EasierOWL, not EasierRDF.

[dbooth-boston]

@afs, as the home page says: "This repository is for experimental/exploratory work on making RDF easier to use, . . . . By "RDF" we mean the whole RDF ecosystem -- including SPARQL, OWL, tools, standards, educational materials, etc. -- everything that a developer touches when using RDF."