Re: ShEx relation to SPIN/OWL

I'd like to back up a little and discuss the need for something other than 
OWL and SPARQL.

As has been mentioned, OWL was not intended for validation. Both OWL and 
RDFS are intended to infer new triples from a given set of triples. OWL 
also has the characteristic that in some cases a reasoner will determine 
that a set of triples is inconsistent. For example, x owl:differentThan x 
is always inconsistent. At first glance this looks like a way to do 
constraint checking. Unfortunately, an OWL reasoner will go to great 
lengths to infer triples in order to make a given set of triples 
consistent. You can't easily use OWL to even do cardinality checking. For 
example, suppose you assert that :hasFather is a functional property, and 
you have the triples :Luke :hasFather :Anakin and :Luke :hasFather :Darth. 
An OWL reasoner will invoke the Non-Unique Naming Assumption to infer that 
:Anakin owl:sameAs :Darth.

Several years ago Evren Siren et al proposed an alternate semantics for 
OWL (using CWA) so that it could be used for integrity constraint (IC) 
checking and this is implemented in the Stardog database. However, this 
OWL IC semantics was never submitted to a standards organization. This gap 
motivated us at Open Services for Lifecycle Collaboration (OSLC) to 
propose the Shapes specification several years ago. It was recently 
submitted to W3C.

IMHO, it would be somewhat confusing to have two completely different 
semantics for OWL. Nevertheless, had the IC semantics for OWL been 
standardized, I don't think we'd be having this discussion now.

On the other hand, SPARQL does seem ideally suited to constraint checking. 
You can run an ASK query on some triples to determine if a constraint is 
satisfied. You can run a SELECT or CONSTRUCT query to find why a 
constraint is not satisfied. SPARQL is very expressive, so most typical 
constraints can be expressed. However, SPARQL is too low-level. If you 
look at a SPARQL query, you'd have a hard time figuring out what 
constraint it is checking.

In several use cases, it is required to have a human-understandable 
description of simple integrity constraints such as domain, range, and 
cardinality. For example:
1) describe requests and responses for an RDF REST API
2) provide metadata to a SPARQL query builder
3) provide metadata to a data entry form builder
4) generate human-readable documentation

Another important requirement is that a constraint language should be 
independent of any vocabulary or ontology since it is often the case that 
an RDF document combines terms from multiple sources. Both OWL and RDFS 
fail on this count. In fact, it is a best practice to reuse existing terms 
rather than invent new synonyms. You should be able to define constraints 
on any RDF document that contains any set of terms. Furthermore, the 
constraints may vary depending on the context. For example, you may have 
different constraints on a request body that you POST versus a response 
body that you GET.

Ideally, we'd have a high-level, human-friendly language for constraining 
RDF and it would be easily translatable to SPARQL to make its semantics 
clear and to give us a standard way to automatically check the 
constraints. The high-level language should have an RDF representation, 
but could also have other serializations that are easier to author. IMHO, 
Turtle is easy to author, but other syntaxes could be more compact. A 
complete solution would also provide a way to drop down into SPARQL syntax 
so you can describe arbitrary constraints.


Regards, 
___________________________________________________________________________
Arthur Ryman, PhD

Chief Data Officer, Rational
Chief Architect, Portfolio & Strategy Management
Distinguished Engineer | Master Inventor | Academy of Technology

Toronto Lab | +1-905-413-3077 (office) | +1-416-939-5063 (mobile)





From:   "Eric Prud'hommeaux" <eric@w3.org>
To:     John Snelson <John.Snelson@marklogic.com>, 
Cc:     "john.walker" <john.walker@semaku.com>, "public-rdf-shapes@w3.org" 
<public-rdf-shapes@w3.org>
Date:   07/03/2014 09:42 AM
Subject:        Re: ShEx relation to SPIN/OWL



* John Snelson <John.Snelson@marklogic.com> [2014-07-03 10:31+0000]
> Hi John,
> 
> On 03/07/14 08:18, john.walker wrote:
> > I know many people who would consider SPARQL to be a declarative
> > language, albeit not with the specific purpose of validation.
> 
> SPARQL is a declarative language for querying RDF. ShEx is a declarative 

> language for describing RDF shapes. With declarative languages it's 
> vital to talk about the context in which it is declarative.
> 
> > Even with a declarative validation language I would expect, in many
> > real-world use cases, there is more than one way to skin a cat.
> > I'm not sure I understand your last point about an RDF based syntax, 
do
> > you mean RDF/XML specifically here?
> 
> I certainly don't mind there being an RDF representation of ShEx, but 
> there also needs to be a syntax that is easily written and read.

Just as an FYI, there's a View as <Resource Shapes> link in the ShEx
Demo so you can get some idea what it would look like in RDF.


> > Personally I think it is pretty cool to have an RDF representation of
> > ShEx that could be serialized to any of the concrete RDF syntaxes.
> > Primarily for these reasons:
> > - ShEx could be stored in a graph store
> > - ShEx could be used to validate itself
> > - ShEx could be queried or constructed using SPARQL
> 
> Agreed, although syntax is not the only factor here. XML Schema has an 
> XML based syntax, but going from the XML syntax to a usable 
> representation of the model is so complicated that it's not generally 
> considered feasible in XSLT/XQuery.

Because RNG has a start token, I was able to do something like this with 
RNC:
  http://www.w3.org/2004/02/03-rdal/
, but I used perl and DOM and that sort of stuff (to compile XSLT).
I agree, coercing something into your representation model is only the 
first,
and probably the easiest, step


> John

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Thursday, 3 July 2014 14:58:56 UTC