W3C home > Mailing lists > Public > public-rdf-shapes@w3.org > August 2014

Re: Proposed change to the charter, section 4. Deliverables, Recommendation Track

From: Holger Knublauch <holger@topquadrant.com>
Date: Sun, 03 Aug 2014 19:29:18 +1000
Message-ID: <53DE00EE.9060001@topquadrant.com>
To: "public-rdf-sha." <public-rdf-shapes@w3.org>
Hi Dimitris,

yes such exercises are important and should be done at some stage. I 
guess the actual WG could tackle those. This discussion thread here is 
all about the charter so that we can start a WG in the foreseeable 
future. I therefore believe you may want to open a separate email thread 
for your specific proposal. I don't understand your "it would be more 
interesting".

I am sure there are other, similar example scenarios, including the SKOS 
Integrity Constraints [1] and the hundreds of use cases to be collected 
by the requirements task force. It is fairly obvious to me that no 
single approach will be the ideal choice for all of them, which is why I 
believe that a combination of

1) SPIN (to bring in the flexibility of SPARQL, and as a meta-language 
for 2)
2) A Shapes vocabulary (as a collection of frequently needed constraints 
that is easy-to-use)
3) OWL Closed World (for existing ontologies and OWL compliance)

will be our safest bet to satisfy most requirements. The list above 
outlines the three mandatory deliverables that I would like to see.

Regards,
Holger

[1] http://www.w3.org/2001/sw/wiki/SKOS/Validation


On 8/3/2014 18:30, Dimitris Kontokostas wrote:
>
>
>
> On Sun, Aug 3, 2014 at 9:21 AM, Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>     A pragmatic proposal: I do believe there is consensus that this WG
>     can potentially create some useful and relevant output that could
>     lead to broader use cases for semantic web technology as a whole.
>     There are several proposals on the table that are potentially
>     complementary to each other. Assuming there are enough people who
>     actually sign up for the work, why not produce multiple
>     deliverables that cover more use cases?
>
>     1) Shapes + SPIN, with an explicit mandate to have semantics that
>     are executable by SPARQL engines, from day one. The alternative
>     would be ShEx and this could be figured out in the beginning of
>     the WG. This deliverable would be like an extension to SPARQL.
>
>     plus
>
>     2) OWL closed world semantics, so that existing OWL ontologies can
>     be reused. This deliverable would basically be an "appendix" to
>     the OWL 2 spec.
>
>     This would allow the interest groups to stay on their home turf
>     without blocking each other, because blocking each other would be
>     the worst outcome of all. I see no technical difficulties with
>     such as stack, because these technologies are complementary to
>     each other: we use OWL closed world + SPIN all the time, and it
>     works well in practice. In fact I believe both specifications have
>     a good and stable starting point so that we could proceed with the
>     process very swiftly.
>
>
> From my POV it would be more interesting to do a comparison in action 
> by implementing PROV Constraints 
> (http://www.w3.org/TR/prov-constraints/) in all proposed solutions 
> (ShEx, SPIN, Shapes, ICV, OWL).
> I think PROV is a nice use case because it has a moderate complexity 
> and can reveal weaknesses / strengths in terms of expressivity, 
> readability & compactness. A plus would be to capture the constraints 
> of the PROV ontology in CWA.
> Paul Groth already made an attempt to port these constraints in SPIN 
> [1] but I am not aware if these are complete or optimized.
>
> In addition this would be a great contribution to the PROV community.
>
> @Arthur, Eric, Jose
> It would be great if you could shed some light in the actual 
> differences between ShEx and Shapes (besides the syntax and the 
> property group extensions by ShEx)
>
> Best,
> Dimitris
>
> [1] 
> https://github.com/pgroth/prov-constraints-validator-spin/blob/master/python/prov-constraints.py
>
>
>     Peter, would this be an acceptable direction for you?
>
>     Thanks,
>     Holger
>
>
>
>     On 8/3/14, 9:14 AM, Peter F. Patel-Schneider wrote:
>
>         I have indicated that I am satisfied with the current mention
>         of possible solutions at the end of Section 3.
>
>         The work currently mentioned there is targeted towards RDF
>         validation.  I am not in favour of including work that is not
>         targeted towards RDF validation. If SPARQL fits into this
>         category then I am not in favour of including SPARQL in this
>         part of the charter at all.
>
>         I have never indicated that all possible solutions have to be
>         included in the charter.  Suggesting this is just
>         inflammatory.  I have never indicated that no possible
>         solutions can be included in the charter.  Suggesting this is
>         also inflammatory.
>
>         I am in favour of including multiple possible solutions, and
>         in favour of including the ones that I think have sufficient
>         gravitas.
>
>
>
>         Why do you think that SPARQL should be given the prominent
>         place in the charter that it has in your suggested wording for
>         deliverables?
>
>
>         peter
>
>
>
>
>
>         On 08/02/2014 03:37 PM, Irene Polikoff wrote:
>
>             Sort of. I believe you are interpreting "a blank sheet" in
>             a very literal sense of the words which is clearly not
>             what I meant. Other than that, I wanted to clarify if you
>             are saying:
>
>             1) It is OK to state the possible solution in the charter
>             as long as it is not mentioned in the deliverables section or
>             2) It is OK to state the possible solution in the charter
>             as long as it is not SPARQL or
>             3) The charter should not mention any possible solutions
>             anywhere or
>             4) The charter should equally mention all possible
>             solutions that may exist in the world irrespective of
>             their maturity and the number of such possible alternatives or
>             5) some combination of the above or something else altogether
>
>             Irene
>
>             -----Original Message-----
>             From: Peter F. Patel-Schneider
>             [mailto:pfpschneider@gmail.com
>             <mailto:pfpschneider@gmail.com>]
>             Sent: Saturday, August 02, 2014 6:11 PM
>             To: Irene Polikoff; 'Arthur Ryman';
>             public-rdf-shapes@w3.org <mailto:public-rdf-shapes@w3.org>
>             Subject: Re: Proposed change to the charter, section 4.
>             Deliverables, Recommendation Track
>
>             You indeed have misunderstood my position.
>
>             I don't think that I have previously indicated that
>             starting with a blank sheet is suboptimal, although I do
>             agree that it is generally not a good idea.
>                No charter draft that I have seen does start with a
>             blank sheet, so this is somewhat of a moot point.
>
>             There are several implemented and deployed systems that
>             claim to provide constraints for RDF.  Not all of them are
>             given meaning in terms of SPARQL.
>             There is new work that claims to provide constraints for
>             RDF. It is not based on SPARQL at all.  I have seen no
>             work showing that SPARQL is adequate as an underpinning of
>             all these systems.  Under these circumstances I feel that
>             it is completely wrong to have SPARQL mentioned at all in
>             the deliverables of the working group.
>
>             It this clear enough for you?
>
>             peter
>
>
>
>
>             On 08/02/2014 02:54 PM, Irene Polikoff wrote:
>
>                 Peter,
>
>                 I thought you agreed that starting with a blank sheet
>                 has proven to be suboptimal to ensuring success of a
>                 working group and its timely progress. And that while
>                 you were not against SPARQL per se, you were concerned
>                 with mandating its use in case the working group finds
>                 that it does not satisfy requirements.
>
>                 Since my proposed wording addresses both of the
>                 issues, I must have misunderstood your position.
>
>                 Irene
>
>                 -----Original Message-----
>                 From: Peter F. Patel-Schneider
>                 [mailto:pfpschneider@gmail.com
>                 <mailto:pfpschneider@gmail.com>]
>                 Sent: Saturday, August 02, 2014 5:09 PM
>                 To: Irene Polikoff; 'Arthur Ryman';
>                 public-rdf-shapes@w3.org <mailto:public-rdf-shapes@w3.org>
>                 Subject: Re: Proposed change to the charter, section
>                 4. Deliverables,
>                 Recommendation Track
>
>                 Again, your proposed wording goes far beyond simply
>                 mentioning a possible solution.  Your proposed wording
>                 says that a particular approach is to be followed
>                 unless it is shown to be inadequate.
>
>                 I do not support this proposed wording.  I do support
>                 wording like what is currently at the end of Section 3.
>
>                 peter
>
>
>                 On 08/02/2014 01:21 PM, Irene Polikoff wrote:
>
>                     Because it identifies a possible solution and says
>                     that if it proves to be inadequate, the working
>                     group will choose another approach. Thus, the
>                     prime candidate is identified, but the group is
>                     not mandated to use it.
>
>                     -----Original Message-----
>                     From: Peter F. Patel-Schneider
>                     [mailto:pfpschneider@gmail.com
>                     <mailto:pfpschneider@gmail.com>]
>                     Sent: Saturday, August 02, 2014 4:18 PM
>                     To: Irene Polikoff; 'Arthur Ryman';
>                     public-rdf-shapes@w3.org
>                     <mailto:public-rdf-shapes@w3.org>
>                     Subject: Re: Proposed change to the charter,
>                     section 4. Deliverables,
>                     Recommendation Track
>
>                     Why would you think that this would be acceptable
>                     to me? This goes well beyond pointing at possible
>                     solutions or mentioning possible starting points.
>
>                     peter
>
>                     On 08/02/2014 01:13 PM, Irene Polikoff wrote:
>
>                         Then, Arthur's strawman with the modification
>                         below should be acceptable:
>
>                         The WG MUST produce:
>
>                         1. A high-level RDF vocabulary that expresses
>                         commonly occurring constraints.
>                         2. The semantics of the high-level constraints
>                         expressed in terms of SPARQL or, if SPARQL
>                         proves to be unsuitable for the use cases
>                         determined by the group, in an alternative
>                         language.
>                         3. An RDF extension mechanism for expressing
>                         additional constraints, expressed in SPARQL.
>
>                         The WG MAY produce:
>
>                         1. A new compact, human readable syntax for
>                         expressing constraints with a corresponding
>                         semantics expressed in SPARQL or, if SPARQL
>                         proves to be unsuitable for the use cases
>                         determined by the group, in an alternative
>                         language.
>                         2. A specification of how constraint
>                         validation interacts with inference.
>                         3. A specification for graph normalization.
>                         [1] http://www.w3.org/2014/data-shapes/charter
>
>                         Irene
>
>                         -----Original Message-----
>                         From: Peter F. Patel-Schneider
>                         [mailto:pfpschneider@gmail.com
>                         <mailto:pfpschneider@gmail.com>]
>                         Sent: Saturday, August 02, 2014 1:17 AM
>                         To: Irene Polikoff; 'Arthur Ryman';
>                         public-rdf-shapes@w3.org
>                         <mailto:public-rdf-shapes@w3.org>
>                         Subject: Re: Proposed change to the charter,
>                         section 4.
>                         Deliverables, Recommendation Track
>
>                         I don't see much wrong in pointing at
>                         potential solutions, and even less mentioning
>                         possible starting points, but that's not what
>                         the proposed change to the charter is. Instead
>                         the proposed change mandates SPARQL as the
>                         semantics of constraints.  I think that this
>                         is in advance of any worked-out proposal for
>                         actually using SPARQL for this purpose.
>
>                         If it turns out that SPARQL can be used to
>                         specify the semantics of constraints, then it
>                         may be reasonable to use SPARQL for this purpose.
>                         However, mandating SPARQL's use even before
>                         its suitability has been demonstrated doesn't
>                         seem to me to be a good idea.
>
>                         peter
>
>
>                         On 08/01/2014 06:54 PM, Irene Polikoff wrote:
>
>                             Not necessarily. As Jeremy Carroll said in
>                             one of the previous e-mails "W3C
>                             experience indicates that a WG with a
>                             blank sheet at the beginning often
>                             delivers the wrong stuff, late - and the
>                             broad ship that sails ends up as a narrow
>                             clique on arrival".
>
>                             It is better to set a charter that
>                             identifies the prime candidate. As the
>                             work proceeds, the group may decide that
>                             the candidate doesn’t meet key
>                             requirements, but having initial stake in
>                             the ground is important to the
>                             effectiveness of the group, its ability to
>                             deliver on time and quality of its
>                             deliverables.
>
>                             Irene
>
>                             -----Original Message-----
>                             From: Peter F. Patel-Schneider
>                             [mailto:pfpschneider@gmail.com
>                             <mailto:pfpschneider@gmail.com>]
>                             Sent: Friday, August 01, 2014 5:53 PM
>                             To: Arthur Ryman; public-rdf-shapes@w3.org
>                             <mailto:public-rdf-shapes@w3.org>
>                             Subject: Re: Proposed change to the
>                             charter, section 4.
>                             Deliverables, Recommendation Track
>
>                             All these arguments may be fine, but isn't
>                             that up to the working group to decide?
>
>                             peter
>
>
>                             On 08/01/2014 02:42 PM, Arthur Ryman wrote:
>
>                                 Peter,
>
>                                 Thx for the response. I'm glad that we
>                                 agree on making the
>                                 compact, human-friendly syntax optional.
>
>                                 Here is my rationale for advocating
>                                 for the use of SPARQL.
>
>                                 1. We need to be precise about the
>                                 meaning of constraints.
>                                 Therefore, we need to select some
>                                 formalism for expressing the semantics.
>
>                                 2. The candidates for expressing
>                                 semantics include:
>                                 2.1 Natural language
>                                 2.2 OWL ICV
>                                 2.3 SPARQL
>                                 2.4 Z
>                                 2.5 some other existing formal language
>                                 2.6 a new specification language that
>                                 the wg invents
>
>                                 Pros and Cons
>
>                                 2.1 Natural language is imprecise and
>                                 non-executable
>                                 2.2 OWL ICV is well-defined and
>                                 executable, but not a W3C standard
>                                 and is not expressive enough as a
>                                 general constraint language
>                                 2.3 SPARQL is a W3C standard, is very
>                                 expressive, and is
>                                 executable
>                                 2.4 Z is very expressive but not well
>                                 known and is non-executable
>                                 2.5 There are many other formal
>                                 specification languages. Does
>                                 anyone want to advocate for one?
>                                 2.6 A new formalism - not the core
>                                 focus of the workgroup.
>
>                                 3. Some one will need to build a
>                                 reference implementation. A
>                                 SPARQL implementation will be easy to
>                                 build if the semantics of
>                                 the constraints are in SPARQL.
>
>                                 4. We want the specification to be
>                                 implemented and adopted. SPARQL
>                                 is a known quantity and many
>                                 implementations exist.
>
>
>                                 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
>                                 <tel:%2B1-905-413-3077> (office) |
>                                 +1-416-939-5063
>                                 <tel:%2B1-416-939-5063> (mobile)
>
>
>
>
>
>                                 From:   "Peter F. Patel-Schneider"
>                                 <pfpschneider@gmail.com
>                                 <mailto:pfpschneider@gmail.com>>
>                                 To:     Arthur
>                                 Ryman/Toronto/IBM@IBMCA,
>                                 public-rdf-shapes@w3.org
>                                 <mailto:public-rdf-shapes@w3.org>,
>                                 Date:   08/01/2014 05:22 PM
>                                 Subject:        Re: Proposed change to
>                                 the charter, section 4.
>                                 Deliverables, Recommendation   Track
>
>
>
>                                 I do agree that the emphasis in the
>                                 charter on creating a
>                                 human-readable syntax is misplaced and
>                                 that this deliverable
>                                 should be made optional. The proposal
>                                 here, however, does very
>                                 much more than fixing this problem,
>                                 and I view most of the other
>                                 changes in the proposal as undesirable.
>
>                                 Why should the group be required to
>                                 specify semantics in terms of SPARQL?
>                                 There hasn't even been anything to
>                                 show that SPARQL is adequate
>                                 for this purpose.  Why should the
>                                 group be required to specify two
>                                 ways of expressing constraints, and
>                                 one of them be SPARQL itself?
>                                 There hasn't been anything to show
>                                 that this division is needed.
>                                 Why should a human-readable syntax for
>                                 constraints be new?  There
>                                 hasn't been anything to show that
>                                 existing syntaxes are unsuitable
>                                 for this purpose.  I don't think that
>                                 it is appropriate to tie the
>                                 hands of the working group in any of
>                                 these ways.
>
>                                 I do agree that the group should be
>                                 required to define the meaning
>                                 of constraints.  This was a peculiar
>                                 lack in the deliverables.
>
>                                 So my proposal would be to change the
>                                 recommendation track
>                                 deliverables to
>
>                                 something like:
>
>                                 1. A syntax and semantics for shapes
>                                 specifying how to construct
>                                 shape expressions and how shape
>                                 expressions are evaluated against RDF
>                                 graphs.
>
>                                 2. An RDF vocabulary for expressing
>                                 these shapes in RDF triples,
>                                 so they can be stored, queried,
>                                 analyzed, and manipulated with
>                                 normal RDF tools.
>
>                                 3. OPTIONAL A specification of how
>                                 shape verification interacts
>                                 with inference.
>
>                                 4. OPTIONAL A compact, human-readable
>                                 syntax for expressing shapes.
>
>                                 I would prefer the third deliverable
>                                 to be required, but I'm not
>                                 going to complain if it is optional.
>
>                                 Although there are three syntaxes
>                                 mentioned in these deliverables,
>                                 in keeping with the usual RDF
>                                 situation there is nothing saying
>                                 that all of these three need to be
>                                 different or even that they are
>                                 not all the same.  (Well, nothing
>                                 beyond the implausibility of
>                                 using RDF triples as the basis of a
>                                 compact, human-readable
>                                 syntax.)
>
>                                 peter
>
>
>                                 On 08/01/2014 12:44 PM, Arthur Ryman
>                                 wrote:
>
>                                     The output of the wg is defined by
>                                     its deliverables. Here is the
>                                     current text [1]
>
>                                     Recommendation Track:
>                                     1.      Compact, human readable
>                                     syntax for expressing constraints
>                                     on RDF
>                                     graph patterns (aka shapes),
>                                     suitable for the use cases
>                                     determined by
>
>                                 the
>
>                                     group. This syntax might be a
>                                     variation of an existing standard,
>                                     such as templates for SPARQL, or
>                                     something new, such as ShExC.
>                                     2.      An RDF vocabulary, such as
>                                     Resource Shapes 2.0, for expressing
>                                     these shapes in RDF triples, so
>                                     they can be stored, queried,
>                                     analyzed,
>
>                                 and
>
>                                     manipulated with normal RDF tools.
>                                     The WG MAY produce a
>                                     Recommendation for graph
>                                     normalization.
>
>                                     This text is not acceptable to IBM
>                                     because of the primary
>                                     emphasis it places on defining a
>                                     possibly new compact, human
>                                     readable syntax.
>                                     I believe this concern has been
>                                     expressed repeatedly by many
>                                     people on the mailing list. Many
>                                     people have indicated a strong
>                                     preference for
>
>                                 building
>
>                                     on existing standards. However, we
>                                     have not seen any
>                                     corresponding modification of the
>                                     charter. I'd therefore like to
>                                     propose a strawman change to this
>                                     section of the charter and invite
>                                     comment.
>                                     Here is the proposed new text:
>                                     The WG MUST produce:
>                                     1. A high-level RDF vocabulary
>                                     that expresses commonly occurring
>                                     constraints.
>                                     2. The semantics of the high-level
>                                     constraints expressed in terms
>                                     of SPARQL.
>                                     3. An RDF extension mechanism for
>                                     expressing additional
>                                     constraints, expressed in SPARQL.
>                                     The WG MAY produce:
>                                     1. A new compact, human readable
>                                     syntax for expressing
>                                     constraints with
>
>                                 a
>
>                                     corresponding semantics expressed
>                                     in SPARQL.
>                                     2. A specification for graph
>                                     normalization.
>                                     [1]
>                                     http://www.w3.org/2014/data-shapes/charter
>
>                                     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
>                                     <tel:%2B1-905-413-3077> (office) |
>                                     +1-416-939-5063
>                                     <tel:%2B1-416-939-5063> (mobile)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> -- 
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig
> Research Group: http://aksw.org
> Homepage:http://aksw.org/DimitrisKontokostas
Received on Sunday, 3 August 2014 09:30:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:40 UTC