Re: ShEx relation to SPIN/OWL

On Tue, Jul 8, 2014 at 2:11 AM, Eric Prud'hommeaux <eric@w3.org> wrote:

> * Holger Knublauch <holger@topquadrant.com> [2014-07-08 07:16+1000]
> > Yes I agree that in some cases it is important to be able to not be
> > too constrained by declarations that are part of a published model.
> > It is also sometimes not desirable to put constraints into an
> > ontology so that the class and property definitions can be reused
> > from OWL DL tools (and spin:constraint would break that).
> >
> > However, that's exactly what named graphs have been invented for.
> > When we use SPIN, we typically put the classes and properties into
> > one file, and create another file that owl:imports the schema and
> > then only contains the spin:constraints and rules (and helper
> > templates). This way, anyone is able to use just the ontology if
> > they prefer to do that. To get the semantics of both, you simply
> > owl:import the SPIN file.
> >
> > I therefore do not agree that the separation of constraints and
> > schema requires a new language - they can still live in triples (or
> > rather: quads if you like). I may be missing something in your line
> > of thought.
>
> The purpose of the new language was simply to make the schema more
> presentable and editable. During the W3C RDF Validation Workshop, we
> looked at OSCL Resource Shapes, Dublin Core Description Set Profiles
> and SPIN (as in the W3C Member Submission, where spin:constraint
> connects a node in an RDF graph to a SPARQL ASK query [CNST]), OWL
> with closed world and unique name assumption, some SPARQL data
> validation schemes, and some path expressions from Google. The idea of
> a human-facing language had wide appeal during the wrap-up at the end
> of the workshop.
>
> The spl:ObjectCountPropertyConstraint construct that you describe
> below moves SPIN closer to the "syntax" (i.e. graph topology) of
> Resource Shapes and Description Set Profile:
>
>   SPIN             Resource Shapes    Description Set Profile
>   arg:property    oslc:property       dsp:Property
>   arg:minCount    oslc:occurs¹        dsp:minOccurs
>   arg:maxCount    oslc:occurs¹        dsp:maxOccurs
>
> ¹ single terms stand for (0,1), (0,n), (1,1), (1,n) cardinalities
>
>
> I think Arthur's point about separating schema from data was just
> that, if you want re-use of data, you can't attach your structural
> constraints to the types of the nodes. We don't want everyone who uses
> a foaf:Person to have to follow the same rules about whether or not
> their application permits/requires a givenName, an mbox, etc. Nor do
> we want it that a node can only serve one purpose, e.g. that some node
> can't act as both a User and an Employee [UEMP].
>

Regarding the re-usability of the (owl) schemas (again)
When someone reuses a schema (e.g. foaf) in most cases he adheres to the
schema contacts
e.g. givenName has a foaf:Person as a domain and so on, unless he
explicitly overrides the axioms, (but them he has his own ontology).
Then, on top of foaf, he sets his own restrictions, different per use case
(I agree)

In RDFUnit we assign manual restrictions to a URI and this URI can be
reused when loading tests
e.g. we can assign in http://ex.com/app/input, givenName must exists once,
in http://ex.com/app/output, mbox must exists once, and so on
But we can also define manual test cases for schemas like geo <
http://www.w3.org/2003/01/geo/wgs84_pos#>
where we say that

   - -90 < geo:lat < 90
   - -180 < geo:long < 180
   - geo:lat should exist along with a geo:lon

something that *should be valid* for anyone that reuses geo

so when we execute a test, an example configuration is:

 > test this <source> using

   1. the manual test cases for http://ex.com/app/input
   2. automatic & manual test cases for foaf
   3. automatic & manual test cases for geo
   4. automatic & manual test cases for xyz, ...

Note that the same way we re-use vocabularies, we should also be able to
reuse validation rules.
e.g. prov defines their own constraints (
http://www.w3.org/TR/prov-constraints/) why should we rewrite them in our
application and not just link them or extend them?
Note that I am on no way suggesting that this way is perfect, but it was
the best we came up with (at that time) for defining reusable tests and
making the execution more straightforward to the end user

Thus, although I agree that we should decouple the constraints from the
ontologies, there should be a way for automatic discoverability.
I also think ShEx should take modularity & reusability into consideration.

Best,
Dimitris






>
>
> [CNST]
> http://www.w3.org/Submission/2011/SUBM-spin-modeling-20110222/#spin-constraints
> [UEMP] http://www.w3.org/brief/Mzc3
>
>
> > HTH
> > Holger
> >
> >
> >
> > On 7/7/14, 10:45 PM, Arthur Ryman wrote:
> > >Holger,
> > >
> > >Thx. I agree that the example SPIN syntax is high-level enough, like OWL
> > >or RDFS. However, given a common, high-level constraint, we need a
> > >standard name and definition for it so other tools don't have to
> > >understand SPARQL. SPIN can give it a semantics in terms of SPARQL.
> > >
> > >There is one aspect of SPIN that I believe is a problem. You wrote:
> > >
> > >This information "belongs" into the
> > >ontology together with the class and property definitions, and should be
> > >shared as such.
> > >
> > >That agrees with my understanding of SPIN, but I think it's a problem. I
> > >agree that in some cases you do want to associate constraints with a
> class
> > >and in that case the constraints should be part of the ontology.
> However,
> > >there are other use cases where we design RDF documents using existing
> > >vocabularies. There are many vocabularies in common use and it is a best
> > >practice to reuse their terms instead of defining new synonyms. For
> > >example, Dublin Core is widely reused and has very few constraints. In
> > >fact, the fewer constraints in a vocabulary, the more reusable it is.
> You
> > >might want to constrain how Dublin Core is used in a particular case.
> > >
> > >Consider the case where you define a REST service that accepts RDF
> > >requests, and the documents use terms from several existing
> vocabularies.
> > >We need a way to describe the document and the constraints it must
> > >satisfy. For example, the REST service may require that the document
> > >contains exactly one dcterms:title property. Of course, the constraints
> > >must be compatible with the existing vocabularies, i.e. the constraints
> > >must not change the semantics of any term. Furthermore, the constraints
> > >may vary depending on the REST operation.
> > >
> > >We need to decouple the constraint language from the ontology or
> > >vocabulary. There is an analogy with natural language. In natural
> > >languages, a dictionary defines the meaning of terms and a grammar says
> > >how the terms may be combined into text. In RDF, a vocabulary or
> ontology
> > >is like a dictionary, and a shape language is like a grammar. We can't
> put
> > >everything in the ontology.
> > >
> > >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:   Holger Knublauch <holger@topquadrant.com>
> > >To:     public-rdf-shapes@w3.org,
> > >Date:   07/07/2014 01:02 AM
> > >Subject:        Re: ShEx relation to SPIN/OWL
> > >
> > >
> > >
> > >On 7/4/2014 0:58, Arthur Ryman wrote:
> > >>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.
> > >I agree, and believe SPIN ticks most of these boxes already. When you
> > >instantiate SPIN templates you basically end up with the same syntax as
> > >the RDF representation of ShEX. And assuming that a standard library of
> > >templates exists (including templates to represent cardinality and other
> > >frequently needed concepts) then SPIN is also a *declarative* model that
> > >can be queried without even knowing SPARQL. The declarative triples of
> > >the SPIN template calls can be queried just like any other ontological
> > >data to drive user interfaces (selection of widgets) etc.
> > >
> > >Just to re-iterate here is how an example SPIN template call looks like
> > >in Turtle
> > >
> > >:Issue
> > >    spin:constraint [
> > >        rdf:type spl:ObjectCountPropertyConstraint ;
> > >        arg:maxCount 1 ;
> > >        arg:property :reportedBy ;
> > >      ] ;
> > >
> > >It would be trivial to define a template just for that use case, and
> > >reformat it so that it becomes
> > >
> > >:Issue
> > >    spin:constraint [ a ex:Maximum-one ;  ex:property :reportedBy  ] ;
> > >
> > >which is hopefully easy enough to edit. In the snippet above,
> > >ex:Exactly-one would be a SPIN template that defines the actual SPARQL
> > >query to execute via spin:body. I believe this mechanism combines the
> > >flexibility of SPARQL with the simple declarative syntax of RDF triples.
> > >SPIN is self-describing and therefore extensible to any constraint
> > >patterns needed in the future, and it grows with the evolution and
> > >adoption of SPARQL.
> > >
> > >I do wonder what this working group would do if SPIN had already been a
> > >W3C standard (and not just a member submission). Would this have changed
> > >anything?
> > >
> > >FWIW I would strongly recommend to encourage an RDF-based representation
> > >over yet another custom syntax. This information "belongs" into the
> > >ontology together with the class and property definitions, and should be
> > >shared as such. Other languages also require new parsers and just add up
> > >to the learning curve. A good example of what *not* to do with a W3C
> > >standard has been the OWL/XML syntax introduced in OWL 2 - it only leads
> > >to fragmentation and additional implementation costs (even Jena doesn't
> > >support OWL/XML).
> > >
> > >Holger
> > >
> > >
> > >
> > >
> >
> >
>
> --
> -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.
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org
Homepage:http://aksw.org/DimitrisKontokostas