Re: ShEx relation to SPIN/OWL

Hi Eric, John,

On 7/1/2014 20:31, Eric Prud'hommeaux wrote:

> I intended ShEx to be as human readable as possible for the use cases
> in question so I take your challenge as a call to compare it to
> equivalent expressions in SPIN/SPARQL and OWL.

I am attaching a SPIN version of your challenge. The main motivation for 
doing this is to demonstrate that it is very well possible to create 
human-readable representations while having a maximum of expressivity 
(all of SPARQL) and being compatible with a language that many people 
already know.

To start this off, here is a TopBraid Composer screen rendering of the 
spin:constraints defined for the class Issue:



You can see that I am using one SPARQL query and three SPIN template calls.

http://composing-the-semantic-web.blogspot.com.au/2009/01/understanding-spin-templates.html

The Turtle source code of such a template call looks like this:

:Issue
         spin:constraint  [
             a             spl:ObjectCountPropertyConstraint ;
             arg:maxCount  1 ;
             arg:property  :reportedBy
         ] ;

i.e. it is possible to express a constraint on the maximum cardinality 
of a property in just 4 triples (same number as an owl:Restriction would 
use).

At execution time, these template calls are substituted by their SPARQL 
implementation (spin:body). Here is how the constraint template used 
above is defined:



You can see that the template's body is doing the real work, and is 
perfectly reusable across many ontologies. Anyone can create and publish 
their own templates in RDF. A good example of such a library is

http://semwebquality.org/mediawiki/index.php?title=SemWebQuality.org

and TopBraid also includes their own libraries including the SPL 
namespace shown above and attached.

Here is the constraint checking valid phone numbers:



I copied this regex from the internet so I have no idea whether it is 
correct, but you get the idea. Internally, this gets executed using 
FILTER regex in SPARQL, but the user only needs to select the template 
and then fill in the required arguments (here: the property and the 
specific regex string).

The tricky bit of your example is that it requires inferencing to run 
before it can find all violations. One inference that I have implemented 
here infers the rdf:type of a resource if it uses a property with an 
rdfs:domain:

CONSTRUCT {
     ?instance a ?domain .
}
WHERE {
     ?property rdfs:domain ?domain .
     ?instance ?property ?anyValue .
     FILTER NOT EXISTS {
         ?instance a ?anyType .
     } .
}

There are many other ways of achieving the same result, e.g. using an 
out-of-the-box OWL or RDFS inference engine, but I wanted to make the 
example self-contained so this is represented as a SPIN rule.

To run this yourself, you would need TopBraid Composer Free Edition 
4.4.1 and replace the version of spl with the attached one because I 
made some changes for (the yet unpublished) 4.5 version. Then run SPIN 
inferences so that issue4 gets its rdf:type. Then press the Refresh and 
show problems button. Output should be:



For this run above I actually made the tel: value invalid - the regex 
didn't complain about it so maybe it really is a valid URL. I skipped 
the complication of foaf:Agent which would probably require another 
inference rule. Rest assure that it could be represented with similar ease.

Also note that the example file had an error that November 31 did not 
exist, so I have corrected that for this demo.

I am sure it would be possible to fiddle with this example more to 
highlight strengths and weaknesses, but I my quick shot was just meant 
as an illustration.

> = SPARQL =
>
> The ShEx demo also spits out equivalent SPARQL. You can click View as
> <SPARQL query> to see the SPARQL that captures the same semantics. I
> think you'll find it rather daunting to imagine using that as a
> publication format.

My personal take on your SPARQL example is that nobody would write such 
a query. For readability this should be split into multiple SPARQL 
queries. SPIN provides a "natural" framework for doing so, by 
introducing the concept of attaching rules and constraints to classes. 
You will find that the SPIN file looks much less scary than the SPARQL 
in your example.

> = SPIN =
>
> Spin can add a *this* keyword to the above SPARQL, which would allow
> you to break out the clauses from the SPARQL query produced above. I
> haven't tested an example of this, but perhaps you could provide one
> and we can see what semantics it covers with what syntax.

Done. I am especially highlighting the importance of SPIN Templates. 
There is also a concept of SPIN Functions that allows anyone to define 
their own SPARQL functions that encapsulate reusable queries and produce 
easier-to-maintain rules and constraints. My arguments presented in

http://composing-the-semantic-web.blogspot.com.au/2010/04/where-owl-fails.html

remain valid: it is quite possible to cover most of the functionality of 
OWL with SPIN templates, but templates also enable other medium advanced 
users to write their own language extensions. But not everyone will need 
to do that and they don't even need to know that SPARQL exists to use 
template-based SPIN constraints.

Let me finish by saying that I believe it will be easy to change the 
requirements and your example challenge so that other frameworks than 
SPIN become severely disadvantaged. SPARQL is very expressive, so 
anything involving mathematical operations, string manipulation etc 
quickly reaches the limits of other languages.

Happy to discuss further,
Holger